Re: [PATCH v3 1/3] mm: support anonymous stable page

From	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Newsgroups	linux.kernel
Subject	Re: [PATCH v3 1/3] mm: support anonymous stable page
Date	2016-11-28 06:40 +0100
Message-ID	<sImPv-6fc-1@gated-at.bofh.it> (permalink)
References	<sHkwp-6MV-9@gated-at.bofh.it> <sHkwq-6MV-49@gated-at.bofh.it> <sI7GN-4MS-5@gated-at.bofh.it> <sIiiR-3fL-3@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

Hello,

On (11/28/16 09:41), Minchan Kim wrote:
> 
> I'm going on a long vacation so forgive if I respond slowly. :)

no prob. have a good one!


> On Sun, Nov 27, 2016 at 10:19:10PM +0900, Sergey Senozhatsky wrote:
[..]
> > wondering - how many pages can it hold? we are in low memory, that's why we
> > failed to zsmalloc in fast path, so how likely this to worsen memory pressure?
> 
> Actually, I don't have real number to say but a thing I can say surely is
> it's really hard to meet in normal stress test I have done until now.
> That's why it takes a long time to find(i.e., I could encounter the bug
> once two days). But once I understood the problem, I can reproduce the
> problem in 15 minutes.
> 
> About memory pressure, my testing was already severe memory pressure(i.e.,
> many memory failure and frequent OOM kill) so it doesn't make any
> meaningful difference before and after.
> 
> > just asking. in async zram the window between zram_rw_page() and actual
> > write of a page even bigger, isn't it?
> 
> Yes. That's why I found the problem with that feature enabled. Lucky. ;)

I see. just curious, the worst case is deflate compression (which
can be 8-9 slower than lz4) and sync zram. right? are we speaking
of megabytes here?

> > we *probably* and *may be* can try handle it in zram:
> > 
> > -- store the previous clen before re-compression
> > -- check if new clen > saved_clen and if it is - we can't use previously
> >    allocate handle and need to allocate a new one again. if it's less or
> >    equal than the saved one - store the object (wasting some space,
> >    yes. but we are in low mem).
> 
> It was my first attempt but changed mind.
> It can save against crash but broken data could go to the disk
> (i.e., zram). If someone want to read block directly(e.g.,
> open /dev/zram0; read /dev/zram or DIO), it cannot read the data
> forever until someone writes some stable data into that sectors.
> Instead, he will see many decompression failure message.
> It's weired.
>
> I believe stable page problem should be solved by generic layer,
> not driver itself.

yeah, I'm fine with this. at the same, there are chances, I suspect,
that may be we will see some 'regressions'. well, just may be.

	-ss

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [PATCH v3 1/3] mm: support anonymous stable page Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-11-27 14:30 +0100
  Re: [PATCH v3 1/3] mm: support anonymous stable page Minchan Kim <minchan@kernel.org> - 2016-11-28 01:50 +0100
    Re: [PATCH v3 1/3] mm: support anonymous stable page Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-11-28 06:40 +0100

csiph-web