On February 4, 2002 07:30 am, Ingo Molnar wrote:
> On Sun, 3 Feb 2002, Ed Tomlinson wrote:
> > Maybe we can control this with nice. Is the the best or only way to
> > do it? I am not at all sure it is. After all nice is just another
> > knob. The fewer knobs we have to tweak the easier linux is to use.
> >
> > [...] On the other hand if we can figure a way to add a simple and
> > understandable knob that let it perform better under load do not think
> > its a bad thing either.
>
> comparing these two paragraphs you'll see what kind of paradox we face.
> I'm trying to keep the number of external knobs down, and i'm trying to
> revive nice levels as a thing that makes some real difference, while still
> handling all the important cases automatically, wherever we can
I am very much aware of this and agree that the fewer knobs one _has_
to play with the better.
> > One point that seems to get missed is that a group of java threads,
> > posix threads or sometimes forked processes combine to make an
> > application. [...]
>
> yes - but what makes them an application is not really the fact that they
> share the VM (i can very much imagine thread-based login servers where
> different users use different threads - a single application as well?),
> but the intention of the application designer, which is hard to guess.
>
> if this becomes inevitable then perhaps a better line we can guess along
> is the child-parent relationship. Looking at 'pstree' output shows some
> clear application boundaries. I'd say an application are 'all children of
> a parent'. Ie. if two threads (shared VM or not shared VM, does not
> matter) have the same parent (which is not init) then they form an
> 'application'. This will cover FreeNet java threads just as well as
> hundreds of Apache processes.
I had though of this too. This could work ok if we only go back one level.
For my load the ->mm method was more specific though, thinking of Apache,
its probably not general enought.
> but this method is guesswork as well, so it could mishandle certain cases.
> Eg. i'm quite certain that most people would notice the interactive
> effects if we handled all processes forked by kdeinit as a single
> application. So lets do it only if everything else fails to fix your
> workload.
K2 today, will take a day or two to get a real feel of K2 - this week is
going to be a busy one (its time to put our serviced SAP system into
production).
I wonder just how much they will notice though. If we use a scheme like
I implemented for the shared mm, it only triggers under load and then still
runs the interactive tasks first.
BTW, there is another buglet in my code. If we defer a task we need to
check the expired time and set it if its zero. Probably it will not be
but checking it would be a good idea - that is if the code ends up being
required all all.
Ed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:00:33 EST