lkml.org 
[lkml]   [2012]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: NVM Mapping API
    On Tue, May 15, 2012 at 10:46:39AM -0700, Greg KH wrote:
    > On Tue, May 15, 2012 at 09:34:51AM -0400, Matthew Wilcox wrote:
    > > What we'd really like is for people to think about how they might use
    > > fast NVM inside the kernel. There's likely to be a lot of it (at least in
    > > servers); all the technologies are promising cheaper per-bit prices than
    > > DRAM, so it's likely to be sold in larger capacities than DRAM is today.
    > >
    > > Caching is one obvious use (be it FS-Cache, Bcache, Flashcache or
    > > something else), but I bet there are more radical things we can do
    > > with it. What if we stored the inode cache in it? Would booting with
    > > a hot inode cache improve boot times? How about storing the tree of
    > > 'struct devices' in it so we don't have to rescan the busses at startup?
    >
    > Rescanning the busses at startup are required anyway, as devices can be
    > added and removed when the power is off, and I would be amazed if that
    > is actually taking any measurable time. Do you have any numbers for
    > this for different busses?

    Hi Greg,

    I wasn't particularly serious about this example ... I did once time
    the scan of a PCIe bus and it took a noticable number of milliseconds
    (which is why we now only scan the first device for the downstream "bus"
    of root ports and downstream ports).

    I'm just trying to stimulate a bit of discussion of possible usages for
    persistent memory.

    > What about pramfs for the nvram? I have a recent copy of the patches,
    > and I think they are clean enough for acceptance, there was no
    > complaints the last time it was suggested. Can you use that for this
    > type of hardware?

    pramfs is definitely one filesystem that's under investigation. I know
    there will be types of NVM for which it won't be suitable, so rather
    than people calling pramfs-specific functions, the notion is to get a
    core API in the VFS that can call into the various different filesystems
    that can handle the vagaries of different types of NVM.

    Thanks.


    \
     
     \ /
      Last update: 2012-05-16 18:21    [W:0.596 / U:0.144 seconds]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean