[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: Marcus Brinkmann
Subject: Re: quotas [was: thread ids, task ids and subsystems]
Date: Wed, 16 Apr 2003 16:47:00 +0200
User-agent: Mutt/1.5.3i

On Wed, Apr 16, 2003 at 03:16:31PM +0200, Michal 'hramrach' Suchanek wrote:
> 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.

I have never seen any description of how such a currency based model would
work like.  Surely, the vague idea that a user has some amount of "currency"
which it can use to get a restricted resource is clear enough, but it's the
detail that matters.  Who is holding which currency?  Who is providing the
currency to the server, the user or the "bank"?  How are transactions done,
and how are resources reclaimed.

> > 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).

I don't see any issue.  If the server wants to restrict the number of
transactions made, it can do so.  If it wants to coordinate with other
servers (for example, so that a total of transactions overall is not
exceeded), it has to cooperate with those servers.  The user is not
involved, because a user doesn't "own" any amount of database transactions
as far as the operating system is concerned.

If the same mechanisms and servers can be used for the operating system
services and other type of restricted things is a totally different
question, and I would leave this open until I have a better idea on how the
operating system service would look like.

If you want to talk/think about this in more details, try to make up the
biography of a single memory page in the system.  First it would be within
L4, then claimed by sigma0, then passed on to a user as part of a contract.
What happens then?  If a user wants to make a connection to a server, will
the server request memory from the user for internal storage?  If yes, how
will the user be able to reclaim the memory (easy, revoke the mapping), and
how will the server be able to trust the page (Neal's container model enters
the game).  Or will the server be able to negotiate with the memory server
about user's memory?  If yes, how can a user reclaim the memory forcefully,
and how can the user deny such a claim in the first place (the user must
write a "cheque" for the memory that the server can cash in at the memory
server).  And how does all this work in a system like the Hurd where user's
usually can override the functionality of system servers?

It's not at all clear to me what the best of these options is, and that is
only memory.  Processor time is different in that processor time is managed
by the scheduler, and you can not pass it around like memory pages, so maybe
what works best for memory doesn't work at all for processor time.  Servers
running on the user's processor time must negotiate with the system
scheduler that controls the users CPU time, and it needs permission from the
user for that (this would be the second type of transaction from the last
paragraph).  However, what should a server do, if it can not run on the
users time anymore, because the users time is up?  Then it needs to close
the connection, but to close the connection you need CPU time ;)  So a user
can perform something like a subtle DoS attack on the server by using up a
bit of the servers CPU time with each connection.  This doesn't really
worry me, but it is such corner cases which you have to answer, too (even if
the answer is "I don't care"), and note that in general you do care about
this (in EROS, if a thread page faults but has no processor time anymore,
then it stops and the error is silently ignored - this was a bug fix for a
problem that occured where a page fault event was delivered although no
processor time was available for that thread, something that was considered
to be an insecurish DoS type of bug (the exact conditions might have been
different, but it was something like that)).

I don't really worry about resources like bandwidth.  Memory (and maybe
processor time) is most important for the operating system to solve, while
bandwidth is a problem that is constrained to a single (or few) devices, and
thus a smaller problem.


`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/

reply via email to

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