[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: quotas [was: thread ids, task ids and subsystems]

From: Michal 'hramrach' Suchanek
Subject: Re: quotas [was: thread ids, task ids and subsystems]
Date: Wed, 16 Apr 2003 15:16:31 +0200
User-agent: Mutt/1.4i

On Wed, Apr 16, 2003 at 01:17:20PM +0200, Marcus Brinkmann wrote:
> On Wed, Apr 16, 2003 at 12:01:08PM +0200, Michal 'hramrach' Suchanek wrote:
> > IIRC most quota problems were already discussed specifically for memory.
> I am unaware of any discussion of these issues.
That is the "currency based virtual memory" which looks to me like memory
quotas by a different name.
> > The protocol for obtaining memory could be probably generealized for any
> > resource.
> i think you still didn't take into account the unique design features of the
> Hurd.
> > I cannot remember any solution for the problem of reclaiming resources, 
> > which
> > is probably the same for all types of resources.
> If I can not reclaim a resource I provided to an untrusted server, then the
> design is incomplete.

> > It looks like there are basically two types of resources that a user could
> > spend:
> >  - real hardware resources (like memory, cpu time, network bandwidth,
> >     disk space, ...)
> Those are the only resources that matter.
> >  - some artifical resources that may correspond to system resources 
> > indirectly
> > (ie database transactions, file handles, sound records)
> There is no need to care about these in the Hurd.  A file handle is just a
> connection to a server and should be accounted for with the resources the
> server needs to keep the connection.

But it's the user's option to give his raw system resources to a server
process that uses a different type of accounting (ie database transactions).
There's just the question if this could be integrated seamlessly with the
accounting of raw system resources. A general interface could accomplish
this and it would come handy in case new 'real' resources are identified
(or the possibility to impose restrictions on them implemented).

Michal Suchanek

reply via email to

[Prev in Thread] Current Thread [Next in Thread]