Re: [patch 02/13] jffs2 summary allocation: don't use vmalloc()

[Artem Bityutskiy <dedekind@infradead.org>]

Hi,

On Wed, 2008-07-30 at 15:39 -0700, David Brownell wrote:
> > This patch will probably break all sorts of things because that buffer is
> > &*large*: up to half a meg.
> >
> > So this patch isn't mergeable.  I'll hang onto it to bug dmwm2 with when he
> > reincarnates.
> 
> I'm still asking whether MTD folk have any plans to make that stack DMA-safe...
> more than just the SPI flash drivers (mtd_dataflash, m25p80) could benefit
> from DMA support, so I'd hope it's at least being considered.
> 
> If the answer is "no" then (a) the MTD interface specs need to finally say
> they pass DMA-unsafe addresses, and (b) those SPI flash drivers are going
> to need updates.

We use vmalloc() in both UBI and UBIFS because we need to allocate a
large (of eraseblock size) buffer. So this is not just JFFS2. Using
kmalloc() for this does not seem to be a good idea for me, because
indeed the buffer size may be up to 512KiB, and may even grow at some
point to 1MiB.

Using kmalloc() would mean that at some point we would be unable to
allocate these buffers at one go and would have to do things is
fractions smaller than eraseblock size, which is not always easy. So I
am not really sure what is better - to add complexity to JFFS2/UBI/UBIFS
or to teach low levels (which do DMA) to deal with physically
noncontinuous buffers (e.g., DMA only one RAM page at a time).

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)