Hello,
Running an application allocating huge amounts of memory would push some
data from RAM to swap area. After the application terminates, swap area is
usually still occupied.
Is there any way to clean up the swap area by pushing the data back to RAM?
Thanks in advance
Giga
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gregory Giguashvili
Senior Software Engineer
Email: [email protected]
Tel: 972-9-9709379 Fax: 972-3-9709337
Paradigm Geophysical Ltd.
http://www.math.tau.ac.il/~gregoryg
On Tue, 18 Jun 2002, Gregory Giguashvili wrote:
> Hello,
>
> Running an application allocating huge amounts of memory would push some
> data from RAM to swap area. After the application terminates, swap area is
> usually still occupied.
>
> Is there any way to clean up the swap area by pushing the data back to RAM?
>
> Thanks in advance
> Giga
Sure. Execute `swapoff -a`, followed by `swapon -a`. This is no joke.
What didn't get 'pushed' back to RAM is the data from sleeping tasks
that may never wake up for days or years like the daemons that are
awaiting network connections that never happen, or getties that never
get to log-in. So, their data stays on the swap device(s) and their
RAM is freed for use. If you insist in putting this data back into
RAM, thereby wasting RAM, you can do as shown.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
The -AA kernels have fixes for this so it actually reclaims the swap and
*cached* memory as well.
On Tue, 2002-06-18 at 10:56, Gregory Giguashvili wrote:
> Hello,
>
> Running an application allocating huge amounts of memory would push some
> data from RAM to swap area. After the application terminates, swap area is
> usually still occupied.
>
> Is there any way to clean up the swap area by pushing the data back to RAM?
>
> Thanks in advance
> Giga
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Gregory Giguashvili
> Senior Software Engineer
> Email: [email protected]
> Tel: 972-9-9709379 Fax: 972-3-9709337
> Paradigm Geophysical Ltd.
> http://www.math.tau.ac.il/~gregoryg
>
>
> -
> 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/
--
Austin Gonyou <[email protected]>
>Sure. Execute `swapoff -a`, followed by `swapon -a`. This is no joke.
Thanks. That really helped, let alone the fact that swapoff is a lengthy
operation (I can understand why), the resulting memory was even less than
the original RAM+swap size. I guess that happened because of memory
rearrangements when moving it up to RAM.
On Tuesday 18 June 2002 17:10, Richard B. Johnson wrote:
> On Tue, 18 Jun 2002, Gregory Giguashvili wrote:
> > Hello,
> >
> > Running an application allocating huge amounts of memory would push some
> > data from RAM to swap area. After the application terminates, swap area
> > is usually still occupied.
> >
> > Is there any way to clean up the swap area by pushing the data back to
> > RAM?
> >
> > Thanks in advance
> > Giga
>
> Sure. Execute `swapoff -a`, followed by `swapon -a`. This is no joke.
Hmm. Now if you happen to get out of memory during the swapoff part, you'll
get the OO killer on your tail? Or will the system just go freeze solid?
Just a small question.
DK
--
Reclaimer, spare that tree!
Take not a single bit!
It used to point to me,
Now I'm protecting it.
It was the reader's CONS
That made it, paired by dot;
Now, GC, for the nonce,
Thou shalt reclaim it not.
On Tue, 18 Jun 2002, DevilKin wrote:
> On Tuesday 18 June 2002 17:10, Richard B. Johnson wrote:
> > On Tue, 18 Jun 2002, Gregory Giguashvili wrote:
> > > Hello,
> > >
> > > Running an application allocating huge amounts of memory would push some
> > > data from RAM to swap area. After the application terminates, swap area
> > > is usually still occupied.
> > >
> > > Is there any way to clean up the swap area by pushing the data back to
> > > RAM?
> > >
> > > Thanks in advance
> > > Giga
> >
> > Sure. Execute `swapoff -a`, followed by `swapon -a`. This is no joke.
>
> Hmm. Now if you happen to get out of memory during the swapoff part, you'll
> get the OO killer on your tail? Or will the system just go freeze solid?
>
> Just a small question.
I think `swapoff -a` will just fail to remove the swap device/file(s) if
it doesn't have the memory. I've done this with 16 Mb of RAM in the
'good-old-days', where VM was swap.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
On Tue, 18 Jun 2002, Richard B. Johnson wrote:
> On Tue, 18 Jun 2002, DevilKin wrote:
> > On Tuesday 18 June 2002 17:10, Richard B. Johnson wrote:
> > >
> > > Sure. Execute `swapoff -a`, followed by `swapon -a`. This is no joke.
> >
> > Hmm. Now if you happen to get out of memory during the swapoff part, you'll
> > get the OO killer on your tail? Or will the system just go freeze solid?
>
> I think `swapoff -a` will just fail to remove the swap device/file(s) if
> it doesn't have the memory. I've done this with 16 Mb of RAM in the
> 'good-old-days', where VM was swap.
You're right that swapoff should just fail, but sadly we've not done
the work to make that so: the OOM-killer does indeed come in (and it's
not the swapoff task it attacks); and if that can't free enough, then
the system will freeze.
In what forum, by the way, may I suggest to distros that they "rm -rf"
in any tmpfs mounts before shutdown swapoff? It avoids this OOM issue
at shutdown, plus it's a whole lot faster than doing the swapoff.
Hugh
On Tue, 2002-06-18 at 13:26, Gregory Giguashvili wrote:
> >Sure. Execute `swapoff -a`, followed by `swapon -a`. This is no joke.
>
> Thanks. That really helped, let alone the fact that swapoff is a lengthy
> operation (I can understand why), the resulting memory was even less than
> the original RAM+swap size. I guess that happened because of memory
> rearrangements when moving it up to RAM.
Or mmapped files for which pages had been read into memory, but were
freed to make room for your large data allocations.
Jelle
> -
> 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/
On Tue, Jun 18, 2002 at 07:17:00PM +0100, Hugh Dickins wrote:
> In what forum, by the way, may I suggest to distros that they "rm -rf"
> in any tmpfs mounts before shutdown swapoff? It avoids this OOM issue
> at shutdown, plus it's a whole lot faster than doing the swapoff.
actually, debian testing's /etc/init.d/umountfs umounts tmpfs before
swapoff. tmpfs contents are freed on umount, so there's no need for rm -rf
(it would be slower, anyway).
--
Tom Vier <[email protected]>
DSA Key ID 0xE6CB97DA