Re: Avoiding *mandatory* overcommit...

From: Jesse Pollard (pollard@tomcat.admin.navo.hpc.mil)
Date: Tue Apr 04 2000 - 11:25:08 EST


--------- Received message begins Here ---------

>
> Alexander Viro writes:
> >
> > [big, fscking snip]
> >
> > Erm... gentlemen, could we _please_ have this topic taken out of here and
> ^^^^^^^^^
> Bad assumption. Have you missed Linda's posts?
>
> > shot? If somebody _really_ wants to mast^Wdiscuss this stuff - get a
> > spare box and install majordomo. It's not a rocket science. Enough
> > already.
>
> At least it's on-topic. Sure, maybe it's a bit long and most people
> have lost interest by now, but that's hardly unique for linux-kernel.
>
> At the moment, there isn't a strong policy to take intermittent
> "specialist" discussions off-kernel. Perhaps it's time to address that
> broader issue. The volume on linux-kernel has made it almost unusable
> for many developers.

It has also generated the first patch set for resource control. I'm hoping
to test it this week(end?). It's not complete, but it does appear to provide
the option of controling overcommitting memory, and locates where the
accounting may need to be done. Tests are needed to:

1. verify functionality
2. measure the systems actual use (root processes and such)
3. add more performance measures ... (recording process high water marks,
   reqested/used etc.)
4. determine if memory scheduling can be done and is usefull (and how easily
   implemented)
5. decide where patches for user quotas can go (as well as get values loaded)

(no I didn't develop it, but it looks reasonable for the first step)
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Fri Apr 07 2000 - 21:00:12 EST