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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
