Date:	Fri, 15 Jun 2012 14:07:52 -0500
From:	Seth Jennings <sjenning@...ux.vnet.ibm.com>
To:	Dan Magenheimer <dan.magenheimer@...cle.com>
CC:	Nitin Gupta <ngupta@...are.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Minchan Kim <minchan@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Tejun Heo <tj@...nel.org>,
	David Howells <dhowells@...hat.com>, x86@...nel.org,
	Nick Piggin <npiggin@...il.com>,
	Konrad Rzeszutek Wilk <konrad@...nok.org>
Subject: Re: [PATCH v2 3/3] x86: Support local_flush_tlb_kernel_range

>> From: Seth Jennings [mailto:sjenning@...ux.vnet.ibm.com]

>> To add to what Nitin just sent, without the page mapping, zsmalloc and
>> the late xvmalloc have the same issue.  Say you have a whole class of
>> objects that are 3/4 of a page.  Without the mapping, you can't cross
>> non-contiguous page boundaries and you'll have 25% fragmentation in the
>> memory pool.  This is the whole point of zsmalloc.
> 
> Yes, understood.  This suggestion doesn't change any of that.
> It only assumes that no more than one page boundary is crossed.
> 
> So, briefly, IIRC the "pair mapping" is what creates the necessity
> to do special TLB stuff.  That pair mapping is necessary
> to create the illusion to the compression/decompression code
> (and one other memcpy) that no pageframe boundary is crossed.
> Correct?


Yes.

> The compression code already compresses to a per-cpu page-pair
> already and then that "zpage" is copied into the space allocated
> for it by zsmalloc.  For that final copy, if the copy code knows
> the target may cross a page boundary, has both target pages
> kmap'ed, and is smart about doing the copy, the "pair mapping"
> can be avoided for compression.


The problem is that by "smart" you mean "has access to zsmalloc
internals".  zcache, or any user, would need the know the kmapped
address of the first page, the offset to start at within that page, and
the kmapped address of the second page in order to do the smart copy
you're talking about.  Then the complexity to do the smart copy that
would have to be implemented in each user.


> The decompression path calls lzo1x directly and it would be
> a huge pain to make lzo1x smart about page boundaries.  BUT
> since we know that the decompressed result will always fit
> into a page (actually exactly a page), you COULD do an extra
> copy to the end of the target page (using the same smart-
> about-page-boundaries copying code from above) and then do
> in-place decompression, knowing that the decompression will
> not cross a page boundary.  So, with the extra copy, the "pair
> mapping" can be avoided for decompression as well.


This is an interesting thought.

But this does result in a copy in the decompression (i.e. page fault)
path, where right now, it is copy free.  The compressed data is
decompressed directly from its zsmalloc allocation to the page allocated
in the fault path.

Doing this smart copy stuff would move most of the complexity out of
zsmalloc into the user which defeats the purpose of abstracting the
functionality out in the first place: so the each user that wants to do
something like this doesn't have to reinvent the wheel.

--
Seth

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists