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

[Bob Liu <bob.liu@oracle.com>]

On 03/15/2013 05:39 PM, Simon Jeons wrote:
> On 01/22/2013 02:53 PM, Shaohua Li wrote:
>> Hi,
>>
>> Because of high density, low power and low price, flash storage (SSD)
>> is a good
>> candidate to partially replace DRAM. A quick answer for this is using
>> SSD as
>> swap. But Linux swap is designed for slow hard disk storage. There are
>> a lot of
>> challenges to efficiently use SSD for swap:
>>
>> 1. Lock contentions (swap_lock, anon_vma mutex, swap address space lock)
>> 2. TLB flush overhead. To reclaim one page, we need at least 2 TLB
>> flush. This
>> overhead is very high even in a normal 2-socket machine.
>> 3. Better swap IO pattern. Both direct and kswapd page reclaim can do
>> swap,
>> which makes swap IO pattern is interleave. Block layer isn't always
>> efficient
>> to do request merge. Such IO pattern also makes swap prefetch hard.
>> 4. Swap map scan overhead. Swap in-memory map scan scans an array,
>> which is
>> very inefficient, especially if swap storage is fast.
>> 5. SSD related optimization, mainly discard support
>> 6. Better swap prefetch algorithm. Besides item 3, sequentially
>> accessed pages
>> aren't always in LRU list adjacently, so page reclaim will not swap
>> such pages
>> in adjacent storage sectors. This makes swap prefetch hard.
>> 7. Alternative page reclaim policy to bias reclaiming anonymous page.
>> Currently reclaim anonymous page is considering harder than reclaim
>> file pages,
>> so we bias reclaiming file pages. If there are high speed swap
>> storage, we are
>> considering doing swap more aggressively.
>> 8. Huge page swap. Huge page swap can solve a lot of problems above,
>> but both
>> THP and hugetlbfs don't support swap.
> 
> Could you tell me in which workload hugetlb/thp pages can't swapout
> influence your performance? Is it worth?
> 

I'm also very interesting in this workload.
I think hugetlb/thp pages can be a potential user of zprojects like
zswap/zcache.
We can try to compress those pages before breaking them to normal pages.

-- 
Regards,
-Bob

--
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>