[Ksummit-2012-discuss] [ATTEND] Block device runtime suspend, other topics

[David Woodhouse]

I'd like to attend the Kernel Summit this year.

I'm keen to participate in the discussion about PCI/IOMMU/VFIO. I'd also
like to explore the possibility of unifying the IOMMU code a bit more.
It's kind of odd that we have a complete virtual address space allocator
in each IOMMU driver (at least the AMD and Intel ones that I've paid
most attention to), and each provides a *separate* API (the DMA API)
using that allocator automatically, alongside the "IOMMU API" for
virtualisation where the caller provides the virtual address too. There
appears to be scope for simplifying the IOMMU drivers to just perform
the 'map virt X to phys Y' operation, and allow the rest to be handled
in slightly more common code. (Yes, before anyone says it: I know that
some of the ppc64 IOMMUs would probably need to be quite different, so
the common code can't be mandatory.)


The other thing I'm looking at currently is SATA Device Sleep. Basically
it takes an SSD so long to power up and build up its internal
translation tables (they have *huge* amounts of internal RAM these days
to store it all), that we're implementing suspend-to-RAM for "disks".
It's controlled by a GPIO line on a previously unused pin on the SATA
power connector. It would be useful to have a discussion about how we
handle runtime power management of block devices and how, or to what
extent, we involve the file system in that (giving hints that it's not
got dirty buffers which it's likely to flush soon, so we should wake the
disk, etc.)


I'm also interested in the 'bufferbloat' phenomenon that is being widely
discussed, and have found a few instances where Linux suffers from
excessive buffering of packets in its transmit infrastructure. It might
be interesting for someone to give a presentation about that topic, and
lead into a discussion about what we can/should do to address it in the
Linux kernel context.


It would be interesting to invite John Crispin <blogic at openwrt.org> and
one of his contacts from Danube, who produce the Lantiq chipset which is
found in a lot of new ADSL routers. They've been doing an excellent job
of getting it all supported upstream, which I applaud because I've
whined a *lot* at OpenWRT for hoarding patches in the past, and it's
particularly good to such direct support from the hardware vendors. But
there are still sticking points in the workflow, and I think that they
could provide a useful perspective to any discussion about how kernel
maintenance work (or should work).


-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.linux-foundation.org/pipermail/ksummit-2012-discuss/attachments/20120617/03c6d573/attachment-0001.bin>