Swap on Fuse deadlocks?

Swap on Fuse deadlocks?

[John Richard Moser]

I just tried to set up an LZOlayer swap partition:

http://north.one.pl/~kazik/pub/LZOlayer/

The layout was as such:

/tmp/swap_base  - tmpfs (run1), disk (run2)
/tmp/swap - lzolayer swap_base
/tmp/swap/swap0 - 200M swap file
/dev/loop0 - /tmp/swap/swap0 loopback

I turned on loop0, crept anywhere over 10 megs into swap and it seized
up (otherwise it was fine).  This happened in both run1 (swap on tmpfs)
and run2 (swap on disk).

The swap on tmpfs I can understand; it'll essentially loop trying to
allocate new swap, swap in and out parts of the swap file to itself, and
eventually hit a condition where it's trying to swap an area of the swap
file into itself, creating an infinite loop.

Swap on disk I don't get.  A little slow perhaps due to the LZO or zlib
compression in the middle (lzolayer lets you pick either); but a total
freeze?  What's wrong here, is lzo_fs data getting swapped out and then
not swapped in because it's needed to decompress itself?


-- 
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond

    We will enslave their women, eat their children and rape their
    cattle!
                  -- Bosc, Evil alien overlord from the fifth dimension

Re: Swap on Fuse deadlocks?

[Pavel Machek]

On Mon 2006-09-25 17:43:36, John Richard Moser wrote:
> I just tried to set up an LZOlayer swap partition:
> 
> http://north.one.pl/~kazik/pub/LZOlayer/
> 
> The layout was as such:
> 
> /tmp/swap_base  - tmpfs (run1), disk (run2)
> /tmp/swap - lzolayer swap_base
> /tmp/swap/swap0 - 200M swap file
> /dev/loop0 - /tmp/swap/swap0 loopback
> 
> I turned on loop0, crept anywhere over 10 megs into swap and it seized
> up (otherwise it was fine).  This happened in both run1 (swap on tmpfs)
> and run2 (swap on disk).
> 
> The swap on tmpfs I can understand; it'll essentially loop trying to
> allocate new swap, swap in and out parts of the swap file to itself, and
> eventually hit a condition where it's trying to swap an area of the swap
> file into itself, creating an infinite loop.
> 
> Swap on disk I don't get.  A little slow perhaps due to the LZO or zlib
> compression in the middle (lzolayer lets you pick either); but a total
> freeze?  What's wrong here, is lzo_fs data getting swapped out and then
> not swapped in because it's needed to decompress itself?

Yes, possibly. Or maybe lzo_fs needs  to allocate memory and kernel
decides it needs to swap for that?

It is miracle that fuse works for normal write, do not expect it to
work for swap. (Does it even work mmap-ed writes?)
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Swap on Fuse deadlocks?

[Miklos Szeredi]

> > I just tried to set up an LZOlayer swap partition:
> > 
> > http://north.one.pl/~kazik/pub/LZOlayer/
> > 
> > The layout was as such:
> > 
> > /tmp/swap_base  - tmpfs (run1), disk (run2)
> > /tmp/swap - lzolayer swap_base
> > /tmp/swap/swap0 - 200M swap file
> > /dev/loop0 - /tmp/swap/swap0 loopback
> > 
> > I turned on loop0, crept anywhere over 10 megs into swap and it seized
> > up (otherwise it was fine).  This happened in both run1 (swap on tmpfs)
> > and run2 (swap on disk).
> > 
> > The swap on tmpfs I can understand; it'll essentially loop trying to
> > allocate new swap, swap in and out parts of the swap file to itself, and
> > eventually hit a condition where it's trying to swap an area of the swap
> > file into itself, creating an infinite loop.
> > 
> > Swap on disk I don't get.  A little slow perhaps due to the LZO or zlib
> > compression in the middle (lzolayer lets you pick either); but a total
> > freeze?  What's wrong here, is lzo_fs data getting swapped out and then
> > not swapped in because it's needed to decompress itself?
> 
> Yes, possibly. Or maybe lzo_fs needs  to allocate memory and kernel
> decides it needs to swap for that?
> 
> It is miracle that fuse works for normal write, do not expect it to
> work for swap. (Does it even work mmap-ed writes?)

No.  Though with the dirty page accounting and callback in 2.6.18 it
would be possible to add writable mmap support.

This is next on my todo list once fuse-2.6.0 is out and I have a
little spare time.

Miklos

RE: Swap on Fuse deadlocks?

[David Schwartz]

> Swap on disk I don't get.  A little slow perhaps due to the LZO or zlib
> compression in the middle (lzolayer lets you pick either); but a total
> freeze?  What's wrong here, is lzo_fs data getting swapped out and then
> not swapped in because it's needed to decompress itself?

The filesystem would have to make sure to lock in memory itself and any code it might need. Obviously, if the filesystem code itself gets swapped out, you cannot swap it back in again ever. Any user-space filesystem that expects to handle swap had better call 'mlock'.

DS

Re: Swap on Fuse deadlocks?

[Pavel Machek]

On Mon 2006-09-25 17:08:13, David Schwartz wrote:
> 
> > Swap on disk I don't get.  A little slow perhaps due to the LZO or zlib
> > compression in the middle (lzolayer lets you pick either); but a total
> > freeze?  What's wrong here, is lzo_fs data getting swapped out and then
> > not swapped in because it's needed to decompress itself?
> 
> The filesystem would have to make sure to lock in memory itself and any code it might need. Obviously, if the filesystem code itself gets swapped out, you cannot swap it back in again ever. Any user-space filesystem that expects to handle swap had better call 'mlock'.
> 

mlock is certainly neccessary, but I am not sure it is enough. Linux
VM was not designed with "swap over userspace" in mind.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html