On Thu, Nov 19, 2015 at 10:55:25AM -0500, Brian Foster wrote: > On Wed, Nov 18, 2015 at 12:46:21AM +0200, Octavian Purdila wrote: > > Naive implementation for non-mmu architectures: allocate physically > > contiguous xfs buffers with alloc_pages. Terribly inefficient with > > memory and fragmentation on high I/O loads but it may be good enough > > for basic usage (which most non-mmu architectures will need). > > > > This patch was tested with lklfuse [1] and basic operations seems to > > work even with 16MB allocated for LKL. > > > > [1] https://github.com/lkl/linux > > > > Signed-off-by: Octavian Purdila <octavian.purdila@xxxxxxxxx> > > --- > > Interesting, though this makes me wonder why we couldn't have a new > _XBF_VMEM (for example) buffer type that uses vmalloc(). I'm not > familiar with mmu-less context, but I see that mm/nommu.c has a > __vmalloc() interface that looks like it ultimately translates into an > alloc_pages() call. Would that accomplish what this patch is currently > trying to do? vmalloc is always a last resort. vmalloc space on 32 bit systems is extremely limited and it is easy to exhaust with XFS. Also, vmalloc limits the control we have over allocation context (e.g. the hoops we jump through in kmem_alloc_large() to maintain GFP_NOFS contexts), so just using vmalloc doesn't make things much simpler from an XFS perspective. > I ask because it seems like that would help clean up the code a bit, for > one. It might also facilitate some degree of testing of the XFS bits > (even if utilized sparingly in DEBUG mode if it weren't suitable enough > for generic/mmu use). We currently allocate and map the buffer pages > separately and I'm not sure if there's any particular reasons for doing > that outside of some congestion handling in the allocation code and > XBF_UNMAPPED buffers, the latter probably being irrelevant for nommu. > Any other thoughts on that? We could probably clean the code up more (the allocation logic is now largely a historic relic) but I'm not convinced yet that we should be spending any time trying to specifically support mmu-less hardware. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
