public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Mark Tinguely <tinguely@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 0/2] xfs: fix some new memory allocation failures
Date: Wed, 4 Sep 2013 06:04:01 +1000	[thread overview]
Message-ID: <20130903200401.GF23571@dastard> (raw)
In-Reply-To: <5225DF07.4080509@sgi.com>

On Tue, Sep 03, 2013 at 08:07:19AM -0500, Mark Tinguely wrote:
> On 09/02/13 17:20, Dave Chinner wrote:
> >On Mon, Sep 02, 2013 at 12:03:37PM -0500, Mark Tinguely wrote:
> >>On 09/02/13 05:52, Dave Chinner wrote:
> >>>Hi folks,
> >>>
> >>>These failures are a result of order-4 allocations being done on v5
> >>>filesystems to support the large ACL count xattrs. The first patch
> >>>puts out usual falbback to vmalloc workaround in place. The second
> >>>patch factors all the places we now have this fallback-to-vmalloc
> >>>and makes it transparent to the callers.
> >>>
> >>>Cheers,
> >>>
> >>>Dave.
> >>
> >>Thanks for clean up. Broken record time: Do we really need order
> >>allocation in the filesystem? Esp in xfs_ioctl.c.
> >
> >I don't understand your question. Are you asking why we need high
> >order allocation?
> >
> >Cheers,
> >
> >Dave.
> 
> In patch 2, why not drop the physically contiguous allocation
> attempt and just do the virtually contiguous allocation?

Because:

	a) virtual memory space is extremely limited on some
	platforms - we regularly get people reporting that they've
	exhausted vmalloc space on 32 bit systems.
	b) when there is free contiguous memory, allocating that
	contiguous memory is much faster than allocating
	virtual memory.
	c) virtual memory access is slower than physical memory
	access and it puts pressure on the page tables.

IOWs, we want to avoid allocating virtual memory if at all possible.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-09-03 20:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-02 10:52 [PATCH 0/2] xfs: fix some new memory allocation failures Dave Chinner
2013-09-02 10:52 ` [PATCH 1/2] xfs: fix memory allocation failures with ACLs Dave Chinner
2013-09-06 19:59   ` Mark Tinguely
2013-09-02 10:53 ` [PATCH 2/2] xfs: factor all the kmalloc-or-vmalloc fallback allocations Dave Chinner
2013-09-06 20:37   ` Mark Tinguely
2013-09-02 17:03 ` [PATCH 0/2] xfs: fix some new memory allocation failures Mark Tinguely
2013-09-02 22:20   ` Dave Chinner
2013-09-03 13:07     ` Mark Tinguely
2013-09-03 20:04       ` Dave Chinner [this message]
2013-09-03 20:46         ` Mark Tinguely
2013-09-03 21:16           ` Dave Chinner
2013-09-03 22:38             ` Mark Tinguely
2013-09-10 22:40 ` Ben Myers

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=20130903200401.GF23571@dastard \
    --to=david@fromorbit.com \
    --cc=tinguely@sgi.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