On Thu, Jun 02, 2016 at 09:25:19AM +0900, Minchan Kim wrote:
On Wed, Jun 01, 2016 at 04:09:26PM +0200, Vlastimil Babka wrote:
quoted
On 06/01/2016 01:21 AM, Minchan Kim wrote:
[...]
quoted
Cc: Sergey Senozhatsky <redacted>
Signed-off-by: Minchan Kim <minchan@kernel.org>
I'm not that familiar with zsmalloc, so this is not a full review. I was
just curious how it's handling the movable migration API, and stumbled
upon some things pointed out below.
quoted
@@ -252,16 +276,23 @@ struct zs_pool {
*/
#define FULLNESS_BITS 2
#define CLASS_BITS 8
+#define ISOLATED_BITS 3
+#define MAGIC_VAL_BITS 8
struct zspage {
struct {
unsigned int fullness:FULLNESS_BITS;
unsigned int class:CLASS_BITS;
+ unsigned int isolated:ISOLATED_BITS;
+ unsigned int magic:MAGIC_VAL_BITS;
This magic seems to be only tested via VM_BUG_ON, so it's presence
should be also guarded by #ifdef DEBUG_VM, no?
Thanks for the point.
Then, I want to change it to BUG_ON because struct zspage corruption
is really risky to work rightly and want to catch on it in real product
which disable CONFIG_DEBUG_VM for a while until make the feature stable.
Andrew,
Please fold this patch into zsmalloc: page migration support.
Thanks!