Re: swapoff() runs forever

[Richard Weinberger]

Am 09.04.2012 20:40, schrieb Hugh Dickins:
> On Mon, 9 Apr 2012, Richard Weinberger wrote:
> > Am 09.04.2012 07:35, schrieb Konstantin Khlebnikov:
> > > Richard Weinberger wrote:
> > > > Hi!
> > > >
> > > > I'm observing a strange issue (at least on UML) on recent Linux kernels.
> > > > If swap is being used the swapoff() system call never terminates.
> > > > To be precise "while ((i = find_next_to_unuse(si, i)) != 0)" in try_to_unuse()
> > > > never terminates.
> > > >
> > > > The affected machine has 256MiB ram and 256MiB swap.
> > > > If an application uses more than 256MiB memory swap is being used.
> > > > But after the application terminates the free command still reports that a few
> > > > MiB are on my swap device and swappoff never terminates.
> > >
> > > After last tmpfs changes swapoff can take minutes.
> > > Or this time it really never terminates?
> >
> > I've never waited forever. ;-)
>
> Your lack of dedication is disappointing.
>
> > Once I've waited for>30 minutes.
> >
> > I don't think that it's related to tmpfs because it happens
> > also while shutting down the system after all filesystems have been unmounted.
>
> Like you I'd assume that it is really was going to be forever,
> rather than swapoff just being characteristically slow:
> a few MiB left on swap shouldn't take long to get off.
>
> I've not seen any such issue in recent months (or years), but
> I've not been using UML either.  The most likely cause that springs
> to mind would be corruption of the vmalloc'ed swap map: that would
> be very likely to cause such a hang.

Okay, I'll dig into this.

> You say "recent Linux kernels": I wonder what "recent" means.
> Is this something you can reproduce quickly and reliably enough
> to do a bisection upon?

It happens quite reliably on 3.2 and 3.3.
On 3.1 and 3.0 sometimes.
I've already wasted half a day with bisecting it.

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/