#1457 closed defect (fixed)

Unnecessary read from device driver in case we have READ_AHEAD entry in CACHE

Reported by: Oleg Owned by: Sebastian Huber
Priority: normal Milestone: 4.10
Component: fs Version: 4.10
Severity: normal Keywords:
Cc: thomas.doerfler@…, chrisj@…, nbkolchin@…, sebastian.huber@…, Oleg.Kravtsov@… Blocked By:
Blocking:

Description

When we turn on read ahead feature and read blocks in sequence, the code does not use already pre-read blocks and start reading them from driver, which might reduce performance.

According to rtems_bdbuf_get_buffer() function, it can return a buffer in READ_AHEAD state that keeps valid data, and that should be returned by rtems_bdbuf_read() function, BUT instead of this rtems_bdbuf_read() initiates a new data transfer!

The problem is because we should have checked if a block is in either CACHED, MODIFIED, or READ_AHEAD state, but right now the code checks if a block is in CACHED or MODIFIED states only.

Actually I can't understand why READ_AHEAD state exists, it is actually not a state but rather attribute, because all READ_AHEAD buffers are the same as buffers in CACHED state (i.e. keep valid data), but the difference is that READ_AHEAD buffers are in ready list, and CACHED not there.

I.e. I believe that READ_AHEAD state should be removed and use a single CACHED state for it, but the way how it is handled will be indirectly show that it is read ahead, i.e. javing a CACHED buffer in ready list means that it was read ahead. I do not see any speciality or usefulness for READ_AHEAD state, but this is the matter of another Bug.

Simple test:

  • enable read ahead in the image;
  • read block #N (as the result this will read ahead some more blocks - depending on the configuration);
  • read block #N+1 (there should be no access to the media), BUT right now there is access.

Attachments (1)

bdbuf_read_ahead.patch (366 bytes) - added by Oleg on Oct 28, 2009 at 3:45:39 PM.
Patch to fix exactly this problem

Download all attachments as: .zip

Change History (7)

Changed on Oct 28, 2009 at 3:45:39 PM by Oleg

Attachment: bdbuf_read_ahead.patch added

Patch to fix exactly this problem

comment:1 Changed on Nov 2, 2009 at 8:55:01 AM by Oleg

Cc: nbkolchin@… Oleg.Kravtsov@… added

comment:2 Changed on Nov 4, 2009 at 2:59:42 PM by Oleg

Cc: thomas.doerfler added

comment:3 Changed on Nov 4, 2009 at 3:11:24 PM by thomas.doerfler

Cc: Sebastian Huber added

comment:4 Changed on Nov 4, 2009 at 3:21:38 PM by Sebastian Huber

Cc: Chris Johns added

comment:5 Changed on Nov 20, 2009 at 8:49:52 AM by Sebastian Huber

Owner: changed from Joel Sherrill to Sebastian Huber

comment:6 Changed on Dec 28, 2009 at 11:21:26 AM by Oleg

Resolution: fixed
Status: newclosed

The initial problem seems to be fixed. At least your re-worked version does not seem to have this bug.

Note: See TracTickets for help on using tickets.