linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Octavian Purdila <octavian.purdila@intel.com>
Cc: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] xfs: support for non-mmu architectures
Date: Thu, 19 Nov 2015 10:55:25 -0500	[thread overview]
Message-ID: <20151119155525.GB13055@bfoster.bfoster> (raw)
In-Reply-To: <1447800381-20167-1-git-send-email-octavian.purdila@intel.com>

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@intel.com>
> ---

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?

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?

>  fs/xfs/xfs_buf.c | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
> index 8ecffb3..50b5246 100644
> --- a/fs/xfs/xfs_buf.c
> +++ b/fs/xfs/xfs_buf.c
...
> @@ -816,11 +835,19 @@ xfs_buf_get_uncached(
>  	if (error)
>  		goto fail_free_buf;
>  
> +#ifdef CONFIG_MMU
>  	for (i = 0; i < page_count; i++) {
>  		bp->b_pages[i] = alloc_page(xb_to_gfp(flags));
>  		if (!bp->b_pages[i])
>  			goto fail_free_mem;
>  	}
> +#else
> +	bp->b_pages[0] = alloc_pages(flags, order_base_2(page_count));
> +	if (!bp->b_pages[0])
> +		goto fail_free_buf;
> +	for (i = 1; i < page_count; i++)
> +		bp->b_pages[i] = bp->b_pages[i-1] + 1;
> +#endif

We still have a path into __free_page() further down in this function if
_xfs_buf_map_pages() fails. Granted, _xfs_buf_map_pages() should
probably never fail in this case, but it still looks like a land mine at
the very least.

Brian

>  	bp->b_flags |= _XBF_PAGES;
>  
>  	error = _xfs_buf_map_pages(bp, 0);
> -- 
> 1.9.1
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2015-11-19 15:55 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-17 22:46 [RFC PATCH] xfs: support for non-mmu architectures Octavian Purdila
2015-11-19 15:55 ` Brian Foster [this message]
2015-11-19 20:54   ` Octavian Purdila
2015-11-20 15:11     ` Brian Foster
2015-11-19 23:35   ` Dave Chinner
2015-11-20 14:09     ` Octavian Purdila
2015-11-20 15:11     ` Brian Foster
2015-11-20 15:35       ` Octavian Purdila
2015-11-20 15:40         ` Brian Foster
2015-11-20 20:36       ` Dave Chinner
2015-11-20 22:47         ` Brian Foster
2015-11-22 22:04           ` Dave Chinner
2015-11-23 12:50             ` Brian Foster
2015-11-23 21:00               ` Dave Chinner
2015-11-19 23:24 ` Dave Chinner
2015-11-19 23:54   ` Richard Weinberger
2015-11-20  0:58     ` Dave Chinner
2015-11-20 14:26       ` Octavian Purdila
2015-11-20 15:24         ` Brian Foster
2015-11-20 15:31           ` Octavian Purdila
2015-11-20 15:43             ` Brian Foster
2015-11-20 20:07         ` Theodore Ts'o
2015-11-20 13:43   ` Octavian Purdila
2015-11-20 21:08     ` Dave Chinner
2015-11-20 22:26       ` Octavian Purdila
2015-11-22 22:44         ` Dave Chinner
2015-11-23  1:41           ` Octavian Purdila
2015-11-23 21:46             ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151119155525.GB13055@bfoster.bfoster \
    --to=bfoster@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=octavian.purdila@intel.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).