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

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

 



On Mon, Mar 18, 2013 at 06:38:29PM +0800, Bob Liu wrote:
> 
> 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.

I don't have particular workload and don't have data for obvious reason. What I
expected is swapout hugetlb/thp is to reduce some overheads (eg, tlb flush) and
improve IO pattern.

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