Messages in this thread |  | | Subject | Re: Break 2.4 VM in five easy steps | From | (Eric W. Biederman) | Date | 06 Jun 2001 13:28:16 -0600 |
| |
Mike Galbraith <mikeg@wen-online.de> writes:
> On 6 Jun 2001, Eric W. Biederman wrote: > > > Derek Glidden <dglidden@illusionary.com> writes: > > > > > > > The problem I reported is not that 2.4 uses huge amounts of swap but > > > that trying to recover that swap off of disk under 2.4 can leave the > > > machine in an entirely unresponsive state, while 2.2 handles identical > > > situations gracefully. > > > > > > > The interesting thing from other reports is that it appears to be kswapd > > using up CPU resources. Not the swapout code at all. So it appears > > to be a fundamental VM issue. And calling swapoff is just a good way > > to trigger it. > > > > If you could confirm this by calling swapoff sometime other than at > > reboot time. That might help. Say by running top on the console. > > The thing goes comatose here too. SCHED_RR vmstat doesn't run, console > switch is nogo... > > After running his memory hog, swapoff took 18 seconds. I hacked a > bleeder valve for dead swap pages, and it dropped to 4 seconds.. still > utterly comatose for those 4 seconds though.
At the top of the while(1) loop in try_to_unuse what happens if you put in. if (need_resched) schedule(); It should be outside all of the locks. It might just be a matter of everything serializing on the SMP locks, and the kernel refusing to preempt itself.
Eric
- 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/
|  |