> Mike Galbraith <email@example.com> writes:
> > On 6 Jun 2001, Eric W. Biederman wrote:
> > > Mike Galbraith <firstname.lastname@example.org> writes:
> > >
> > > > > 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.
> > That did it.
> Does this improve the swapoff speed or just allow other programs to
> run at the same time? If it is still slow under that kind of load it
> would be interesting to know what is taking up all time.
> If it is no longer slow a patch should be made and sent to Linus.
No, it only cures the freeze. The other appears to be the slow code
pointed out by Andrew Morton being tickled by dead swap pages.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/