Messages in this thread | | | Date | Wed, 16 Apr 2003 11:16:05 +1000 | From | Nick Piggin <> | Subject | Re: Benefits from computing physical IDE disk geometry? |
| |
Chuck Ebbert wrote:
>Nick Piggin wrote: > > > >>OK right. As far as I can see, the algorithm in the RAID1 code >>is used to select the best drive to read from? If that is the >>case then I don't think it could make better decisions given >>more knowledge. >> > > > How about if it just asks the elevator whether or not a given read >is a good fit with its current workload? I saw in 2.5 where the balance >code is looking at the number of pending requests and if it's zero then >it sends it to that device. Somehow I think something better than >that could be done, anyway. > That balance code is probably the IDE or SCSI channel balancing? In that case, the driver simply wants to know which device it should service next, which is an appropriate fit (is that what you were talking about? I don't have source here sorry)
We could ask the elevator if a given read is a good fit. It would probably help.
> > > >>It seems to me that a better way to layer it would be to have >>the complex (ie deadline/AS/CFQ/etc) scheduler handling all >>requests into the raid block device, then having a raid >>scheduler distributing to the disks, and having the disks >>run no scheduler (fifo). >> > > > That only works if RAID1 is working at the physical disk level (which >it should be AFAIC but people want flexibility to mirror partitions.) > How so? Basically you want your high level scheduler to run first. You want it to act on the stream of requests from the system, not on the stream of requests to the device. If you know what I mean.
I might be wrong here. I haven't done any testing, and only a little bit of thinking.
> > > >>In practice the current scheme probably works OK, though I >>wouldn't know due to lack of resources here :P >> > > > I've been playing with the 2.4 read balance code and have some >improvements, but real gains need a new approach. > The problem I see, is the higher level schedulers (deadline for example, as opposed to the RAID scheduler) will find it difficult to tell if a request will be "good" for them or not. For example we have 2 devices, 100 requests in each scheduler queue.
Device A's head is at sector x and next request is at x+100, Device B's head is at sector x+10 and next request is at x+200.
RAID wants to know which queue should take a request at sector x+1000. What do you do?
The way you would do a good "goodness" function, I guess, would be to search through all requests on the device, and return the minimum distance from the request you are running the query on. Do this for both queues, and insert the request into the queue with the smallest delta. I don't see much else doing any good.
On the other hand, if you simply have a fifo after the RAID scheduler, the RAID scheduler itself knows where each disk's head will end up simply by tracking the value of the last sector it has submitted to the device. It also has the advantage that it doesn't have "high level" scheduling stuff below it ie. request deadline handling, elevator scheme, etc.
This gives the RAID scheduler more information, without taking any away from the high level scheduler AFAIKS.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |