Messages in this thread | | | From | Al Boldi <> | Subject | Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5 | Date | Sat, 8 Apr 2006 23:31:56 +0300 |
| |
Peter Williams wrote: > Al Boldi wrote: > > Can you try the attached mem-eater passing it the number of kb to be > > eaten. > > > > i.e. '# while :; do ./eatm 9999 ; done' > > > > This will print the number of bytes eaten and the timing in ms. > > > > Adjust the number of kb to be eaten such that the timing will be less > > than timeslice (120ms by default for spa). Switch to another vt and > > start pressing enter. A console lockup should follow within seconds for > > all spas except ebs. > > This doesn't seem to present a problem (other than the eatme loop being > hard to kill with control-C) on my system using spa_ws with standard > settings. I tried both UP and SMP. I may be doing something wrong or > perhaps don't understand what you mean by a console lock up.
Switching from one vt to another receives hardly any response.
This is especially visible in spa_no_frills, and spa_ws recovers from this lockup somewhat and starts exhibiting this problem as a choking behavior.
Running '# top d.1 (then shift T)' on another vt shows this choking behavior as the proc gets boosted.
> When you say "less than the timeslice" how much smaller do you mean?
This depends on your machine's performance. On my 400MhzP2 UP 128MB, w/ spa_no_frills default settings, looping eatm 9999 takes 63ms per eat and causes the rest of the system to be starved. Raising kb to 19999 takes 126ms which is greater than the default 120ms timeslice and causes no system starvation.
What numbers do you get?
Thanks!
-- Al
- 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/
| |