From: Artem Bityutskiy <dedekind1@gmail.com>
To: Grant Erickson <marathon96@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH v2] MTD: Retry Read/Write Transfer Buffer Allocations
Date: Tue, 05 Apr 2011 07:48:21 +0300 [thread overview]
Message-ID: <1301978901.2608.38.camel@koala> (raw)
In-Reply-To: <1301941174-10050-1-git-send-email-marathon96@gmail.com>
On Mon, 2011-04-04 at 11:19 -0700, Grant Erickson wrote:
> When handling user space read or write requests via mtd_{read,write},
> exponentially back off on the size of the requested kernel transfer
> buffer until it succeeds or until the requested transfer buffer size
> falls below the page size.
>
> This helps ensure the operation can succeed under low-memory,
> highly-fragmented situations albeit somewhat more slowly.
>
> v2: Added __GFP_NOWARN flag and made common retry loop a function
> as recommended by Artem.
>
> Signed-off-by: Grant Erickson <marathon96@gmail.com>
> ---
> drivers/mtd/mtdchar.c | 66 +++++++++++++++++++++++++++++++++---------------
> 1 files changed, 45 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
> index 145b3d0d..df9be51 100644
> --- a/drivers/mtd/mtdchar.c
> +++ b/drivers/mtd/mtdchar.c
> @@ -166,11 +166,44 @@ static int mtd_close(struct inode *inode, struct file *file)
> return 0;
> } /* mtd_close */
>
> -/* FIXME: This _really_ needs to die. In 2.5, we should lock the
> - userspace buffer down and use it directly with readv/writev.
> -*/
> +/* Back in April 2005, Linus wrote:
> + *
> + * FIXME: This _really_ needs to die. In 2.5, we should lock the
> + * userspace buffer down and use it directly with readv/writev.
> + *
> + * The implementation below, using mtd_try_alloc, mitigates allocation
> + * failures when the sytem is under low-memory situations or if memory
> + * is highly fragmented at the cost of reducing the performance of the
> + * requested transfer due to a smaller buffer size.
> + *
> + * A more complex but more memory-efficient implementation based on
> + * get_user_pages and iovecs to cover extents of those pages is a
> + * longer-term goal, as intimated by Linus above. However, for the
> + * write case, this requires yet more complex head and tail transfer
> + * handling when those head and tail offsets and sizes are such that
> + * alignment requirements are not met in the NAND subdriver.
> + */
> #define MAX_KMALLOC_SIZE 0x20000
>
> +static void *mtd_try_alloc(size_t *size)
Also, if you do the changes I request and make this function allow scary
kmalloc warnings on the last resort PAGE_SIZE allocation, the "try" in
the function name becomes not very appropriate, because in the kernel
APIs it is usually used for something like "try, if did not succeed, no
worry, just return". E.g., mutex_try_lock() or something.
I think it is better to name it mtd_alloc or something like this, but
without "try".
And probably you want to reuse this function in JFFS2, so we should give
it some name which is good for exported API function. May be
mtd_alloc_upto() ? Or mtd_alloc_as_much() ? Or better ideas?
--
Best Regards,
Artem Bityutskiy (Битюцкий Артём)
prev parent reply other threads:[~2011-04-05 4:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-02 0:44 [PATCH] MTD: Retry Read/Write Transfer Buffer Allocations Grant Erickson
2011-04-04 7:27 ` Artem Bityutskiy
2011-04-04 7:41 ` Artem Bityutskiy
2011-04-04 16:05 ` Grant Erickson
2011-04-05 4:39 ` Artem Bityutskiy
2011-04-04 18:19 ` [PATCH v2] " Grant Erickson
2011-04-05 4:39 ` Artem Bityutskiy
2011-04-05 15:54 ` Grant Erickson
2011-04-05 16:54 ` Artem Bityutskiy
2011-04-05 4:48 ` Artem Bityutskiy [this message]
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=1301978901.2608.38.camel@koala \
--to=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=marathon96@gmail.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