lkml.org 
[lkml]   [2010]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Frontswap [PATCH 0/4] (was Transcendent Memory): overview
On 04/25/2010 07:05 PM, Nitin Gupta wrote:
>
>>> Increasing the frequency of discards is also not an option:
>>> - Creating discard bio requests themselves need memory and these
>>> swap devices
>>> come into picture only under low memory conditions.
>>>
>>>
>> That's fine, swap works under low memory conditions by using reserves.
>>
>>
> Ok, but still all this bio allocation and block layer overhead seems
> unnecessary and is easily avoidable. I think frontswap code needs
> clean up but at least it avoids all this bio overhead.
>

Ok. I agree it is silly to go through the block layer and end up
servicing it within the kernel.

>>> - We need to regularly scan swap_map to issue these discards.
>>> Increasing discard
>>> frequency also means more frequent scanning (which will still not be
>>> fast enough
>>> for ramzswap needs).
>>>
>>>
>> How does frontswap do this? Does it maintain its own data structures?
>>
>>
> frontswap simply calls frontswap_flush_page() in swap_entry_free() i.e. as
> soon as a swap slot is freed. No bio allocation etc.
>

The same code could also issue the discard?

>> Even for copying to RAM an async API is wanted, so you can dma it
>> instead of copying.
>>
>>
> Maybe incremental development is better? Stabilize and refine existing
> code and gradually move to async API, if required in future?
>

Incremental development is fine, especially for ramzswap where the APIs
are all internal. I'm more worried about external interfaces, these
stick around a lot longer and if not done right they're a pain forever.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.



\
 
 \ /
  Last update: 2010-04-26 08:09    [W:0.112 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site