Hi, On Tue, 2013-06-18 at 17:02 -0700, Kent Overstreet wrote: > This is a new, from scratch implementation of ida that should be > simpler, faster and more space efficient. > [...]
> > This does mean that the entire bitmap is stored in one contiguous memory > allocation - and as currently implemented we won't be able to allocate > _quite_ as many ids as with the previous implementation. > > I don't expect this to be an issue in practice since anywhere this is > used, an id corresponds to a struct allocation somewher else - we can't > allocate an unbounded number of ids, we'll run out of memory somewhere > else eventually, and I expect that to be the limiting factor in > practice. > > If a user/use case does come up where this matters I can add some > sharding (or perhaps add a separate big_ida implementation) - but the > extra complexity would adversely affect performance for the users that > don't need > millions of ids, so I intend to leave the implementation as > is until if and when this becomes an issue. > Millions of IDs is something that is fairly normal for DLM, since there will be two DLM locks per cached inode with GFS2 and people tend to use it on pretty large servers with lots of memory, Steve. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
