From: Vlastimil Babka <vbabka@suse.cz>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Dan Streetman <ddstreet@ieee.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
Seth Jennings <sjennings@variantweb.net>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH] zswap: update docs for runtime-changeable attributes
Date: Tue, 25 Aug 2015 08:22:03 +0200 [thread overview]
Message-ID: <55DC098B.8080409@suse.cz> (raw)
In-Reply-To: <20150825042224.GB412@swordfish>
On 25.8.2015 6:22, Sergey Senozhatsky wrote:
>>>> i'd argue that neither zbud nor zsmalloc are responsible for reacting
>>>> to memory pressure, they just store the pages. It's zswap that has to
>>>> limit its size, which it does with max_percent_pool.
>>>
>>> Yeah but it's zbud that tracks the aging via LRU and reacts to reclaim requests
>>> from zswap when zswap hits the limit. Zswap could easily add a shrinker that
>>> would relay this requests in response to memory pressure as well. However,
>>> zsmalloc doesn't implement the reclaim, or LRU tracking.
>>
>> I wrote a patch for zsmalloc reclaim a while ago:
>>
>> https://lwn.net/Articles/611713/
>>
>> however it didn't make it in, due to the lack of zsmalloc LRU, or any
>> proven benefit to zsmalloc reclaim.
>>
>> It's not really possible to add LRU to zsmalloc, by the nature of its
>> design, using the struct page fields directly; there's no extra field
>> to use as a lru entry.
>
> Just for information, zsmalloc now registers shrinker callbacks
>
> https://lkml.org/lkml/2015/7/8/497
Yeah but that's just for compaction, not freeing. I think that ideally zswap
should track the LRU on the level of pages it receives as input, and then just
tell zswap/zbud to free them. Then zswap would use its compaction to make sure
that the reclaim results in actual freeing of page frames. Zbud could re-pair
the orphaned half-pages to the same effect.
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Dan Streetman <ddstreet@ieee.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
Seth Jennings <sjennings@variantweb.net>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH] zswap: update docs for runtime-changeable attributes
Date: Tue, 25 Aug 2015 08:22:03 +0200 [thread overview]
Message-ID: <55DC098B.8080409@suse.cz> (raw)
In-Reply-To: <20150825042224.GB412@swordfish>
On 25.8.2015 6:22, Sergey Senozhatsky wrote:
>>>> i'd argue that neither zbud nor zsmalloc are responsible for reacting
>>>> to memory pressure, they just store the pages. It's zswap that has to
>>>> limit its size, which it does with max_percent_pool.
>>>
>>> Yeah but it's zbud that tracks the aging via LRU and reacts to reclaim requests
>>> from zswap when zswap hits the limit. Zswap could easily add a shrinker that
>>> would relay this requests in response to memory pressure as well. However,
>>> zsmalloc doesn't implement the reclaim, or LRU tracking.
>>
>> I wrote a patch for zsmalloc reclaim a while ago:
>>
>> https://lwn.net/Articles/611713/
>>
>> however it didn't make it in, due to the lack of zsmalloc LRU, or any
>> proven benefit to zsmalloc reclaim.
>>
>> It's not really possible to add LRU to zsmalloc, by the nature of its
>> design, using the struct page fields directly; there's no extra field
>> to use as a lru entry.
>
> Just for information, zsmalloc now registers shrinker callbacks
>
> https://lkml.org/lkml/2015/7/8/497
Yeah but that's just for compaction, not freeing. I think that ideally zswap
should track the LRU on the level of pages it receives as input, and then just
tell zswap/zbud to free them. Then zswap would use its compaction to make sure
that the reclaim results in actual freeing of page frames. Zbud could re-pair
the orphaned half-pages to the same effect.
next prev parent reply other threads:[~2015-08-25 6:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-18 19:07 [PATCH] zswap: update docs for runtime-changeable attributes Dan Streetman
2015-08-18 19:07 ` Dan Streetman
2015-08-19 14:02 ` Vlastimil Babka
2015-08-19 14:02 ` Vlastimil Babka
2015-08-19 14:21 ` Dan Streetman
2015-08-19 14:21 ` Dan Streetman
2015-08-19 15:02 ` Vlastimil Babka
2015-08-19 15:02 ` Vlastimil Babka
2015-08-19 15:56 ` Dan Streetman
2015-08-19 15:56 ` Dan Streetman
2015-08-25 4:22 ` Sergey Senozhatsky
2015-08-25 4:22 ` Sergey Senozhatsky
2015-08-25 6:22 ` Vlastimil Babka [this message]
2015-08-25 6:22 ` Vlastimil Babka
2015-08-24 17:33 ` [PATCHv2] " Dan Streetman
2015-08-24 17:33 ` Dan Streetman
2015-09-04 15:22 ` Vlastimil Babka
2015-09-04 15:22 ` Vlastimil Babka
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=55DC098B.8080409@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=ddstreet@ieee.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sjennings@variantweb.net \
/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.