On Tue, Dec 04, 2007 at 01:55:17AM -0600, Rob Landley wrote:
quoted text
> On Monday 03 December 2007 22:26:28 Nick Piggin wrote:
> > There is one slight downside -- direct block device access and filesystem
> > metadata access goes through an extra copy and gets stored in RAM twice.
> > However, this downside is only slight, because the real buffercache of the
> > device is now reclaimable (because we're not playing crazy games with it),
> > so under memory intensive situations, footprint should effectively be the
> > same -- maybe even a slight advantage to the new driver because it can also
> > reclaim buffer heads.
> 
> For the embedded world, initramfs has pretty much rendered initrd obsolete, 
> and that was the biggest user of the ramdisk code I know of.  Beyond that, 
> loopback mounts give you more flexible transient block devices than ramdisks 
> do.  (In fact, ramdisks are such an amazing pain to use/size/free that if I 
> really needed something like that I'd just make a loopback mount in a ramfs 
> instance.)

They are, although we could easily hook up a couple more ioctls for them
now (if anybody is interested).

The rd driver can potentially be a _lot_ more scalable than the loop driver.
It's completely lockless in the fastpath and doesn't even dirty any
cachelines except for the actual destination memory. OK, this is only
really important for testing purposes (eg. testing scalability of a
filesystem etc.) But it is one reason why I (personally) want brd...
 

quoted text
> Embedded users who still want a block interface for memory are generally 
> trying to use a cramfs or squashfs image out of ROM or flash, although there 
> are flash-specific filesystems for this and I dunno if they're actually 
> mounting /dev/mem at an offset or something (md?  losetup -o?  Beats me, I 
> haven't tried that myself yet...)

OK, it would be interesting to hear from anyone using rd for things like
cramfs. I don't think we can get rid of the code entirely, but it sounds
like the few downsides of the new code won't be big problems.

Thanks for the feedback.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/