[U-Boot] [PATCH v2] ext2: Cache line aligned partial sector bounce buffer

Anton Staaf robotboy at google.com
Mon Aug 22 23:48:47 CEST 2011


On Mon, Aug 22, 2011 at 2:42 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Anton Staaf,
>
> In message <1314043924-22130-1-git-send-email-robotboy at chromium.org> you wrote:
>> Currently, if a device read request is done that does not begin or end
>> on a sector boundary a stack allocated bounce buffer is used to perform
>> the read, and then just the part of the sector that is needed is copied
>> into the users buffer.  This stack allocation can mean that the bounce
>> buffer will not be aligned to the dcache line size.  This is a problem
>> when caches are enabled because unaligned cache invalidates are not
>> safe.
>>
>> This patch allocates a cache line size aligned sector sized bounce
>> buffer the first time that ext2fs_devread is called.
>
> ...and never frees ist, which is a bad thing.  Please fix.

That was actually intentional.  To free the buffer the code would need
to know when it was done doing ext2 accesses.  This information isn't
really available.  And it would be a performance hit to allocate and
free the buffer every time a read was performed, instead this patch
re-uses the same allocated buffer every time that the read is called.
Would you prefer that I allocate and free the buffer each time?  I can
see an argument for that since it would mean that the code could also
be called from multiple threads simultaneously, not that we have any
such thing to worry about at the moment.

Thanks,
    Anton

> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> NOTE: The  Most  Fundamental  Particles  in  This  Product  Are  Held
> Together  by  a  "Gluing" Force About Which Little is Currently Known
> and Whose Adhesive Power Can Therefore Not Be Permanently Guaranteed.
>


More information about the U-Boot mailing list