Frontswap [PATCH 0/4] (was Transcendent Memory): overview
in [Kernel]
|
Prev: Whitespace Coding style fixes.
Next: Frontswap [PATCH 1/4] (was Transcendent Memory): swap data structure changes
From: Dan Magenheimer on 26 Apr 2010 08:50 > dma engines are present on commodity hardware now: > > http://en.wikipedia.org/wiki/I/O_Acceleration_Technology > > I don't know if consumer machines have them, but servers certainly do. > modprobe ioatdma. They don't seem to have gained much ground in the FIVE YEARS since the patch was first posted to Linux, have they? Maybe it's because memory-to-memory copy using a CPU is so fast (especially for page-ish quantities of data) and is a small percentage of CPU utilization these days? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dan Magenheimer on 26 Apr 2010 09:00 > > 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. Well if you are saying that your primary objection to the frontswap synchronous API is that it is exposed to modules via some EXPORT_SYMBOLs, we can certainly fix that, at least unless/until there are other pseudo-RAM devices that can use it. Would that resolve your concerns? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 26 Apr 2010 09:50 On 04/26/2010 03:50 PM, Dan Magenheimer wrote: >>> 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. >> > Well if you are saying that your primary objection to the > frontswap synchronous API is that it is exposed to modules via > some EXPORT_SYMBOLs, we can certainly fix that, at least > unless/until there are other pseudo-RAM devices that can use it. > > Would that resolve your concerns? > By external interfaces I mean the guest/hypervisor interface. EXPORT_SYMBOL is an internal interface as far as I'm concerned. Now, the frontswap interface is also an internal interface, but it's close to the external one. I'd feel much better if it was asynchronous. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 26 Apr 2010 09:50 On 04/26/2010 03:45 PM, Dan Magenheimer wrote: >> dma engines are present on commodity hardware now: >> >> http://en.wikipedia.org/wiki/I/O_Acceleration_Technology >> >> I don't know if consumer machines have them, but servers certainly do. >> modprobe ioatdma. >> > They don't seem to have gained much ground in the FIVE YEARS > since the patch was first posted to Linux, have they? > Why do you say this? Servers have them and AFAIK networking uses them. There are other uses of the API in the code, but I don't know how much of this is for bulk copies. > Maybe it's because memory-to-memory copy using a CPU > is so fast (especially for page-ish quantities of data) > and is a small percentage of CPU utilization these days? > Copies take a small percentage of cpu because a lot of care goes into avoiding them, or placing them near the place where the copy is used. They certainly show up in high speed networking. A page-sized copy is small, but many of them will be expensive. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Nitin Gupta on 26 Apr 2010 10:00
On 04/26/2010 11:36 AM, Avi Kivity wrote: > 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? > No, we cannot issue discard bio at this place since swap_lock spinlock is held. Thanks, Nitin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |