From: Konstantin Khlebnikov <khlebnikov@openvz.org>
To: Richard Weinberger <richard@nod.at>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"paul.gortmaker@windriver.com" <paul.gortmaker@windriver.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: swapoff() runs forever
Date: Mon, 09 Apr 2012 09:35:38 +0400 [thread overview]
Message-ID: <4F82752A.6020206@openvz.org> (raw)
In-Reply-To: <4F81F564.3020904@nod.at>
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?
>
> Here some numbers:
> root@linux:~# free
> total used free shared buffers cached
> Mem: 255472 13520 241952 0 312 7080
> -/+ buffers/cache: 6128 249344
> Swap: 262140 17104 245036
> root@linux:~# cat /proc/meminfo
> MemTotal: 255472 kB
> MemFree: 241952 kB
> Buffers: 312 kB
> Cached: 7080 kB
> SwapCached: 0 kB
> Active: 3596 kB
> Inactive: 6076 kB
> Active(anon): 1512 kB
> Inactive(anon): 848 kB
> Active(file): 2084 kB
> Inactive(file): 5228 kB
> Unevictable: 0 kB
> Mlocked: 0 kB
> SwapTotal: 262140 kB
> SwapFree: 245036 kB
> Dirty: 0 kB
> Writeback: 0 kB
> AnonPages: 2296 kB
> Mapped: 1824 kB
> Shmem: 80 kB
> Slab: 2452 kB
> SReclaimable: 1116 kB
> SUnreclaim: 1336 kB
> KernelStack: 192 kB
> PageTables: 556 kB
> NFS_Unstable: 0 kB
> Bounce: 0 kB
> WritebackTmp: 0 kB
> CommitLimit: 389876 kB
> Committed_AS: 238412 kB
> VmallocTotal: 3788784 kB
> VmallocUsed: 68 kB
> VmallocChunk: 3788716 kB
>
> What could cause this issue?
> I'm not sure whether this is UML specific or not.
> Maybe only UML is able to trigger the issue...
>
> Thanks,
> //richard
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Konstantin Khlebnikov <khlebnikov@openvz.org>
To: Richard Weinberger <richard@nod.at>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"paul.gortmaker@windriver.com" <paul.gortmaker@windriver.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: swapoff() runs forever
Date: Mon, 09 Apr 2012 09:35:38 +0400 [thread overview]
Message-ID: <4F82752A.6020206@openvz.org> (raw)
In-Reply-To: <4F81F564.3020904@nod.at>
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?
>
> Here some numbers:
> root@linux:~# free
> total used free shared buffers cached
> Mem: 255472 13520 241952 0 312 7080
> -/+ buffers/cache: 6128 249344
> Swap: 262140 17104 245036
> root@linux:~# cat /proc/meminfo
> MemTotal: 255472 kB
> MemFree: 241952 kB
> Buffers: 312 kB
> Cached: 7080 kB
> SwapCached: 0 kB
> Active: 3596 kB
> Inactive: 6076 kB
> Active(anon): 1512 kB
> Inactive(anon): 848 kB
> Active(file): 2084 kB
> Inactive(file): 5228 kB
> Unevictable: 0 kB
> Mlocked: 0 kB
> SwapTotal: 262140 kB
> SwapFree: 245036 kB
> Dirty: 0 kB
> Writeback: 0 kB
> AnonPages: 2296 kB
> Mapped: 1824 kB
> Shmem: 80 kB
> Slab: 2452 kB
> SReclaimable: 1116 kB
> SUnreclaim: 1336 kB
> KernelStack: 192 kB
> PageTables: 556 kB
> NFS_Unstable: 0 kB
> Bounce: 0 kB
> WritebackTmp: 0 kB
> CommitLimit: 389876 kB
> Committed_AS: 238412 kB
> VmallocTotal: 3788784 kB
> VmallocUsed: 68 kB
> VmallocChunk: 3788716 kB
>
> What could cause this issue?
> I'm not sure whether this is UML specific or not.
> Maybe only UML is able to trigger the issue...
>
> Thanks,
> //richard
next prev parent reply other threads:[~2012-04-09 5:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-08 20:30 swapoff() runs forever Richard Weinberger
2012-04-09 5:35 ` Konstantin Khlebnikov [this message]
2012-04-09 5:35 ` Konstantin Khlebnikov
2012-04-09 10:16 ` Richard Weinberger
2012-04-09 18:40 ` Hugh Dickins
2012-04-09 18:40 ` Hugh Dickins
2012-04-09 19:43 ` Richard Weinberger
2012-04-09 19:43 ` Richard Weinberger
2012-04-11 23:09 ` Richard Weinberger
2012-04-11 23:09 ` Richard Weinberger
2012-04-12 6:40 ` Hugh Dickins
2012-04-12 6:40 ` Hugh Dickins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F82752A.6020206@openvz.org \
--to=khlebnikov@openvz.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=paul.gortmaker@windriver.com \
--cc=richard@nod.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.