Re: [LSF/MM TOPIC]swap improvements for fast SSD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 27 Jan 2013, Shaohua Li wrote:
> On Sat, Jan 26, 2013 at 01:40:55PM +0900, Kyungmin Park wrote:
> > 5. SSD related optimization, mainly discard support.
> > 
> > Now swap codes are based on each swap slots. it means it can't
> > optimize discard feature since getting meaningful performance gain, it
> > requires 2 pages at least. Of course it's based on eMMC. In case of
> > SSD. it requires more pages to support discard.
> > 
> > To address issue. I consider the batched discard approach used at filesystem.
> > *Sometime* scan all empty slot and it issues discard continuous swap
> > slots as many as possible.
> 
> I posted a patch to make discard async before, which is almost good to me,
> though we still discard a cluster. 
> http://marc.info/?l=linux-mm&m=135087309208120&w=2

Any reason why you point to 2012/10/22 patch rather than the 2012/11/19?

Seeing this reminded me to take your 1/2 and 2/2 (of 11/19) out again and
give them a fresh run - though they were easier to apply to 3.8-rc rather
than mmotm with your locking changes, so it was 3.8-rc6 I tried.

As I reported in private mail last year, I wish you'd remove the "buddy"
from description of your 1/2 allocator, that just misled me; but I've not
experienced any problem with the allocator, and I still like the direction
you take with improving swap discard in 2/2.

This time around I've not yet seen any "swap_free: Unused swap offset entry"
messages (despite forgetting to include your later SWAP_MAP_BAD addition to
__swap_duplicate() - I still haven't thought that through to be honest),
but did again get the VM_BUG_ON(error == -EEXIST) in __add_to_swap_cache()
called from add_to_swap() from shrink_page_list().

Since it came after 1.5 hours of load, I didn't give it much thought,
and just went on to test other things, thinking I could easily reproduce
it later; but have failed to do so in many hours since.  Still trying.

Hugh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]