[Gllug] ulimits

[Alex Hudson]

On Sun, Sep 02, 2001 at 10:16:11AM +0100, Jon Masters wrote:
> > You can't just stop a process. It doesn't work like that. Try
> > implementing it on any half-complex program and watch your machine lock
> > up solid.
> 
> That's the challenge.

And obviously this problem, which has evaded some of the best minds in
hard realtime research will be no problem for the mighty jcm ;)

> > scheduling is hardcore compsci.
> 
> ...and what am I studying? Flying pink pandas? It was compsci last time
> I checked. Further, I did happen to spend some time last year reading
> through a couple of the more popular books which include an analysis of
> scheduling.

Wow, you're an undergrad and you've read some books about it? Well, even
though this is doctorate material you're obviously more than qualified.

Note the adjective - 'hardcore'. As in, something beyond the abilities of an
undergrad. I wasn't infering it wasn't in your area, I was infering it was a
problem beyond your abilities. Given you posed the original question means
you have no grounding in this area whatsoever: the people currently working
on solutions have been working on it for years, it's cutting edge, and it's
not something you can just pick up. 

> > I also don't see the point of cutting off users programs at arbitrary
> > limits - what a waste of CPU cycles.
> 
> Yup indeed, especially when a user consumes 100% CPU for 500 squillion
> hours because they forgot to account for condition X occuring.

And this is a problem how? I presume you know how nice works. Unless you're
worried about the power drain of the processor executing real code as
opposed to idling... 

Consuming CPU has no effect on a machine whatsoever. How the machine reacts
depends on how it is setup. If users are run low priority, then the machine
is still able to do its work. The real problem is people running rampant in
swap, because that then does make a task switch hurt. So, setting up memory
limits etc. make sense, and this is something the OS can manage effectively. 

> > If you are actually serious about this area of research you're on the wrong
> > operating system.
> 
> Without meaning to be rude, who are you to tell us we are on the wrong
> OS?

Linux is not a research OS. Find me a paper researching OS principles on
Linux (not 'an implementation of x principle on Linux', but, 'new principle
X with example implementation for Linux') and I'll show you twenty on Mach.
Mach is a research OS. That's what it was built for. That's what it's good
at. People writing Resource Kernels do it on Mach. Linux just isn't suited
for that kind of work. Use the right tool for the right job. 

If you then manage to get a system that works, by all means port it to
Linux. But it's much simpler to start on Mach. And it's so unlikely that
you'll ever write something which works in the way you want, even on Mach,
that the question of the port becomes moot :P.

Cheers,

Alex.

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug