On 05.04.2011 08:32, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 05.04.2011 07:33, Aravind Srinivasan wrote:
>> include/grub/disk.h
>> <snip>
>> /* The size of a disk cache in sector units.  */
>> #define GRUB_DISK_CACHE_SIZE   8
>> #define GRUB_DISK_CACHE_BITS   3
>> <snip>
>>
>> I tried changing this value to 8192 - and the time it took to load 
>> the same
>> image came down to 10 secs !
>> /* The size of a disk cache in sector units.  */
>> #define GRUB_DISK_CACHE_SIZE   8192
>> #define GRUB_DISK_CACHE_BITS   13
>>
>> I am not sure of the reason for setting the cache size to a low value 
>> and any
>> possible issues in increasing this size. Appreciate any input on this.
> This value is a misnomer. It's not a cache size but a cache unit size. 
> As immediate effect it has that if one reads a single 512B, sector one 
> reads an entire block of 4K. Under normal conditions values of around 
> 32K-128K (6-8/64-256) would be optimal. It seems that some EFI 
> implementations do a "buffering" only to discard the buffered data. 
> Some of the reports suggest that this braindamage is limited to disk 
> io and doesn't happen with Block IO. Values you propose would result 
> in 4M reads even when one needs just few sectors and so is suboptimal 
> under normal conditions.
> I'll prepare few patches to investigate.
> After 1.99 the GRUB_DISK_CACHE_BITS will be increased to 6-8 range 
> since, it's optimal and my AF support requires sector size to be 
> smaller than cache unit size.
>
Attached a patch based on my AF patch which change to block IO.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko