From: Artem Bityutskiy <dedekind1@gmail.com>
To: JiSheng Zhang <jszhang3@gmail.com>
Cc: Adrian Hunter <adrian.hunter@nokia.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
"rmk@arm.linux.org.uk" <rmk@arm.linux.org.uk>,
"Bityutskiy Artem (Nokia-D/Helsinki)"
<Artem.Bityutskiy@nokia.com>
Subject: Re: [UBI UBIFS] replace vmalloc with kmalloc
Date: Sun, 09 Aug 2009 08:35:32 +0300 [thread overview]
Message-ID: <1249796132.9157.52.camel@localhost> (raw)
In-Reply-To: <20090807232846.34bffdeb@ustc>
On Fri, 2009-08-07 at 23:28 +0800, JiSheng Zhang wrote:
> Adrian Hunter <adrian.hunter@nokia.com> wrote:
> >
> > vmalloc allows large (> 128KiB) buffers, but kmalloc doesn't.
> > So we presently have no choice but to use vmalloc.
>
> But vmalloced buffer can't be easily passed to DMA, is there better choice?
We use vmalloc-ed buffers is when we need to do something with whole
eraseblocks, which may be 128KiB, or even 256KiB. So in general, we
cannot just s/kmalloc/vmalloc/. We should invent something trickier.
You should probably think about some generic way to solve problems like
this. May be some MTD-specific library could be created. You could
implement something like the flexible arrays, but with DMA stuff in mind
(e.g., adding a parameter which specifies allocation order, because for
DMA you may want to allocate more than one physically contiguous page).
Or you may even improve the existing flexible arrays to suit your needs.
Take a look here:
http://lwn.net/Articles/345273/
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
prev parent reply other threads:[~2009-08-09 5:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-07 9:02 [UBI UBIFS] replace vmalloc with kmalloc JiSheng Zhang
2009-08-07 9:14 ` Matthieu CASTET
2009-08-07 9:20 ` Adrian Hunter
2009-08-07 9:44 ` Russell King
2009-08-07 14:26 ` Josh Boyer
2009-08-07 15:28 ` JiSheng Zhang
2009-08-09 5:35 ` 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=1249796132.9157.52.camel@localhost \
--to=dedekind1@gmail.com \
--cc=Artem.Bityutskiy@nokia.com \
--cc=adrian.hunter@nokia.com \
--cc=dwmw2@infradead.org \
--cc=jszhang3@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=rmk@arm.linux.org.uk \
/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