> > If you access disks or do other similar tasks (login), and there's
> > background process running, you get scheduled at next timer tick - ie.
> > 10ms later. This way, I was able to "feel" background while(1);
> > processes on my 486/16. I'm currently running some tests (find / in
> > fact), to see if this canbe measured in addition to 'felt'.
>
> no. you get scheduled immediately. You can 'feel' it with a background
> process running because starting up a shell is a multi-millisec CPU
> excercise even on fast boxes and fully cached, and processes do not start
> up with excessive priorities. (see how childs and parents share p->counter
> in fork.c) Thus the login is timesharing with the background
> process.
You are probably right.
But in this case, increasing HZ _can_ help, because... No, timeslices
are expected to remain of same length.
Anyway, there's obscure test p->counter > current->counter + 3, which
probably should not be (3 * HZ) / 100. This could do some marginal
difference in some cases.
> but after a few seconds, your shell gathers enough 'interactiveness
> priority' to not hang when you hit 'Enter'.
That agrees with experiment. I just would like login to be fast even
with CPU hogs running in background, automatically (renice them works).
Pavel
-- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+- 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/