Skip to contentSkip to conversation

Linux 2.5.3-pre1-aia1

DISCUSSION Petr Vandrovec 4 participants 5 messages Jan 21, 2002 – Jan 22, 2002

lore
Share & tools
lore

Petr Vandrovec

author
#0 lore raw

I did not want to participate in this discussion, as it is probably impossible to explain to you that there is nothing wrong with doing requests not evenly divisible by block size.

Quoted 15 lines · Andre Hedrick
Quoted 4 lines · Jens Axboe
Quoted 3 lines · Andre Hedrick
Quoted 3 lines

I always thought it is like this (and this is what I still believe after having read the sprcification):

Quoted 9 lines
Quoted 9 lines
Quoted 9 lines

---
SET_MUTIPLE 16 sectors
---
READ_MULTIPLE 24 sectors
IRQ
PIO transfer 16 sectors
IRQ
PIO transfer 8 sectors
---

Quoted 4 lines

255 * 512bytes != 128K BUG
256 * 512bytes == 128K

You insure we will fail on alignemnt.

SET MULTIPLE MODE description says that host should try block size only 1,2,4,8,16,32,64 or 128 sectors. So where you got 255 from?

Quoted 7 lines

You have stated BLOCK can not deal with correct sector alignments, and thus 255 so please fix it first. I have accepted this brokeness in BLOCK and dropped to 128 sectors or a clean 64k.

If we restrict multi-sector PIO to 8 sectors we can do multi interrupt ATOMIC disk IO on the paging alignments, but you have enforced single sector IO in the multi-sector writing and can not see the difference.

Why we cannot do multi-sector PIO with 16...128 sectors? There is no need to read all data with one insw() loop, you can store each of these 64kB of data in 65536 different, non-continuous, locations, and ATA device will not complain, as it will always see 32768 of word reads from its data port, nothing else... And no, there is no requirement that host must do back-to-back reads or writes from ATA device data port. Otherwise we would see upper bound on t0 in PIO-in and PIO-out cycles description.

Quoted 3 lines

If rq->current_nr_sectors is less than 8 we do PIO single sector IO, but we are doing that now w/ the copy paste changes from the old ide-disk.c stuff that we are attempting deleting.

Please tell me what page 168 (it is number of paper page, page number in PDF is by 14 greater) of Volume 2, Revision 0, of ATA/ATAPI rev.7 (T13/1532D) in description of READ MULTIPLE talks about?

If the number of requested sectors is not evenly divisible by the block count, as many full blocks as possible are transferred, followed by a final, partial block transfer. The partial block transfer shall be for n sectors, where n = remainder (sector count/block count).

And almost identical text appears on page 296, where it talks about WRITE MULTIPLE.

If you are trying to persuade us that there are devices which support ATA interface, and do not follow these paragraphs word by word, there is certainly something wrong in the ATA world...
Best regards,
Petr Vandrovec [email protected]

#1 lore raw
Quoted 20 lines · Petr Vandrovec

I did not want to participate in this discussion, as it is probably impossible to explain to you that there is nothing wrong with doing requests not evenly divisible by block size.

Quoted 15 lines · Andre Hedrick
Quoted 13 lines · Jens Axboe
Quoted 12 lines · Andre Hedrick
Quoted 12 lines

I always thought it is like this (and this is what I still believe after having read the sprcification):

---
SET_MUTIPLE 16 sectors
---
READ_MULTIPLE 24 sectors
IRQ
PIO transfer 16 sectors
IRQ
PIO transfer 8 sectors
---

Quoted 7 lines
Quoted 4 lines

255 * 512bytes != 128K BUG
256 * 512bytes == 128K

You insure we will fail on alignemnt.

SET MULTIPLE MODE description says that host should try block size only 1,2,4,8,16,32,64 or 128 sectors. So where you got 255 from?

/storage/src-2.5.3/linux-2.5.3-p2-pristine/drivers/ide

linux/drivers/ide/ide-probe.c

line 627

        /* IDE can do up to 128K per request, pdc4030 needs smaller limit */
        max_sectors = (is_pdc4030_chipset ? 127 : 255);
        blk_queue_max_sectors(q, max_sectors);

/storage/src-2.5.3/linux-2.5.3-p2-pristine/include/linux/blkdev.h

_LINUX_BLKDEV_H

line 322

#define MAX_PHYS_SEGMENTS 128
#define MAX_HW_SEGMENTS 128
#define MAX_SECTORS 255

Quoted 8 lines
Quoted 7 lines

You have stated BLOCK can not deal with correct sector alignments, and thus 255 so please fix it first. I have accepted this brokeness in BLOCK and dropped to 128 sectors or a clean 64k.

If we restrict multi-sector PIO to 8 sectors we can do multi interrupt ATOMIC disk IO on the paging alignments, but you have enforced single sector IO in the multi-sector writing and can not see the difference.

Quoted 7 lines

Why we cannot do multi-sector PIO with 16...128 sectors? There is no need to read all data with one insw() loop, you can store each of these 64kB of data in 65536 different, non-continuous, locations, and ATA device will not complain, as it will always see 32768 of word reads from its data port, nothing else... And no, there is no requirement that host must do back-to-back reads or writes from ATA device data port. Otherwise we would see upper bound on t0 in PIO-in and PIO-out cycles description.

I did not state we can not do the above.
I stated it can be done using multiple interrupts and still return back partial completion of data io, because I thought it was obvious to the execution of the COMMAND BLOCK is ATOMIC. Specifically, once issued, it must complete its operations. If you want to IO more than on page of memory, the you can not have any back until all is done.

No IF's AND's or BUT's and this point is getting totally lost.

Quoted 8 lines
Quoted 3 lines

If rq->current_nr_sectors is less than 8 we do PIO single sector IO, but we are doing that now w/ the copy paste changes from the old ide-disk.c stuff that we are attempting deleting.

Please tell me what page 168 (it is number of paper page, page number in PDF is by 14 greater) of Volume 2, Revision 0, of ATA/ATAPI rev.7 (T13/1532D) in description of READ MULTIPLE talks about?

Quoted 7 lines

If the number of requested sectors is not evenly divisible by the block count, as many full blocks as possible are transferred, followed by a final, partial block transfer. The partial block transfer shall be for n sectors, where n = remainder (sector count/block count).

And almost identical text appears on page 296, where it talks about WRITE MULTIPLE.

This arguement is over how to interface to the kernel and will the kernel allow the device to function.

Quoted 3 lines

If you are trying to persuade us that there are devices which support ATA interface, and do not follow these paragraphs word by word, there is certainly something wrong in the ATA world...

Again not a device issue, it is a HOST-Kernel issue not providing the correct and needed glue layer to allow these operation to happen, as you have so clearly pointed out.

Next if rq->current_nr_sectors is less than MULTI{READ,WRITE} is set for then why do we attempt? The hardware try to help with silly HOST affairs but this one is way to difficult and would cross the ATOMIC nature of the command execute.

In DMA scatter gather it is reference to page locations and it is done.

In PIO there is no scatter gather possible without a memcpy to a contigious buffer period. Therefore under the contstraints issued bu Linus and Jens, of access to one 4k page of memory, and a forced requirement to return back every 4k page of memory of completion prevents one from ever transaction more than 8 sectors per request in PIO any mode.

Regardless if the request is for 128 or 256 sectors, a maximum of 8 sectors may be written or read to any disk, and then the request is ended early. Next the same request minus the first 8 sectors (max possible) is run back up the block layer and re-issued in a new make_request.

start_request_sectors (255 sectors) max

make_request (start_request_sectors())

do_request()
ide-disk get (255 sectors)
block truncates to 8 sectors max
ide-taskfile
transfers 8 sectors max
end request (return 247 sectors)

upate_request(247 to be re issued, + additional max of 8)
make_request (247 to be re issued, + additional max of 8)

Now we never have a way to decide if or when the original PIO request is completed and it is safe to return to DMA if we end up in PIO because of a DMA failure.

This is why I am going to request for backing out again because the BLOCK API without a MID-LAYER to buffer against the goal of the kernel, conflicts with the hardware rules requirements. Until a satisfactory agreement can be reached then the current direction it is going will trash the Virtual DMA hardware coming in the future.

Respectfully,

Andre Hedrick
Linux Disk Certification Project Linux ATA Development

#2 lore raw
In reply to Petr Vandrovec
Quoted 2 lines · Andre Hedrick

In PIO there is no scatter gather possible without a memcpy to a contigious buffer period. Therefore under the contstraints issued bu

Why?

Quoted 3 lines

Linus and Jens, of access to one 4k page of memory, and a forced requirement to return back every 4k page of memory of completion prevents one from ever transaction more than 8 sectors per request in PIO any mode.

You don't understand... It's not forced, it's just _the sane way to do it_. When you finish I/O on a chunk of data, end I/O on that chunk of data. This doesn definitely _not_ prevent transaction of more than 8 sectors per request, that's nonsense. It's only that way in the current kernel because it was easy to get right the first time around. And it's only in multi-write, oh look at multi-read, that does 16 sectors at the time. Weee!

Quoted 7 lines

start_request_sectors (255 sectors) max

make_request (start_request_sectors())

do_request()
ide-disk get (255 sectors)
block truncates to 8 sectors max

                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Wrong

Quoted 2 lines

ide-taskfile
transfers 8 sectors max

                ^^^^^^^^^^^^^^^^^^^^^^^

Wrong

Quoted 3 lines

end request (return 247 sectors)

upate_request(247 to be re issued, + additional max of 8)

end_request _is_ the update request. You seem to not understand that calling ide_end_request does not mean that we are terminating the request from the host side, we are merely asking the block layer to complete xxx amount of sectors for us so we can continue doing the request residual.

Quoted 1 line

make_request (247 to be re issued, + additional max of 8)

Very wrong, make_request is never called here. Let me out line what happens. Do you really mean start_request, if so then yes.

Quoted 3 lines

This is why I am going to request for backing out again because the BLOCK API without a MID-LAYER to buffer against the goal of the kernel, conflicts with the hardware rules requirements. Until a satisfactory

end_that_request_first understands partial completion of any size in 2.5, what more of a mid layer do you want?

Quoted 2 lines

agreement can be reached then the current direction it is going will trash the Virtual DMA hardware coming in the future.

Is that so?

Signature · 1 line
Jens Axboe
#3 lore raw

Last volly for a while ...

Quoted 5 lines · Jens Axboe
Quoted 2 lines · Andre Hedrick

In PIO there is no scatter gather possible without a memcpy to a contigious buffer period. Therefore under the contstraints issued bu

Why?

Okay provide one and a way to referrence from start point and encapsulated around segments.

Quoted 11 lines
Quoted 3 lines

Linus and Jens, of access to one 4k page of memory, and a forced requirement to return back every 4k page of memory of completion prevents one from ever transaction more than 8 sectors per request in PIO any mode.

You don't understand... It's not forced, it's just _the sane way to do it_. When you finish I/O on a chunk of data, end I/O on that chunk of data. This doesn definitely _not_ prevent transaction of more than 8 sectors per request, that's nonsense. It's only that way in the current kernel because it was easy to get right the first time around. And it's only in multi-write, oh look at multi-read, that does 16 sectors at the time. Weee!

We really have a disconnect.

Everytime command register is written to the drive see a new requst.

You are calling this a segment ??

Quoted 10 lines
Quoted 7 lines

start_request_sectors (255 sectors) max

make_request (start_request_sectors())

do_request()
ide-disk get (255 sectors)
block truncates to 8 sectors max

                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Wrong

Exclude DMAing.

When the sector_count register is set to a value smaller than the total request entering, is that not truncating the IO?

Quoted 5 lines
Quoted 2 lines

ide-taskfile
transfers 8 sectors max

                ^^^^^^^^^^^^^^^^^^^^^^^

Wrong

How, the constaints are on 4k boundaries or a single page. 4k == 8-512byte sectors.

Quoted 9 lines
Quoted 3 lines

end request (return 247 sectors)

upate_request(247 to be re issued, + additional max of 8)

end_request _is_ the update request. You seem to not understand that calling ide_end_request does not mean that we are terminating the request from the host side, we are merely asking the block layer to complete xxx amount of sectors for us so we can continue doing the request residual.

Okay, I see there is a lot more code in block to decode. Because the assumption of the ISR's submitted is for exclusive ownership of the request and buffer from head to tail for the duration of the total request. This asumption is similar to DMA executing and total ownership until completing. This may be a folly wrt to interfacing to the block layer.

Quoted 4 lines
Quoted 1 line

make_request (247 to be re issued, + additional max of 8)

Very wrong, make_request is never called here. Let me out line what happens. Do you really mean start_request, if so then yes.

Wait, if the original request requires multiple executions of the command block then they are separate requests.

Quoted 6 lines
Quoted 3 lines

This is why I am going to request for backing out again because the BLOCK API without a MID-LAYER to buffer against the goal of the kernel, conflicts with the hardware rules requirements. Until a satisfactory

end_that_request_first understands partial completion of any size in 2.5, what more of a mid layer do you want?

One which interfaces to the hardware exactly, but it appears not possible. One having the size of the total request and exclusive ownership be mappable for the duration of the IO.

There are issues associated w/ the barrier down block and how to notify. Thus owning the entire buffer exclusive for a flush cache barrier write is needed and may be required. Unless there is a way to notify based on the LBA physical sector or "block" of the beginning of the error reported, problems will arrise in journaling filesystems. The rational for maintaining ownership of an (attempted) ordered write and down block, the hardware will not guarentee the data beyond the error returned from the flush-cache command.

Quoted 4 lines
Quoted 2 lines

agreement can be reached then the current direction it is going will trash the Virtual DMA hardware coming in the future.

Is that so?

Yes but we can cross that path when I release the MMIO driver(s) and core.

So I will wander off and think some more, because I see your reference frame now, but I wonder if you see mine.

Regards,

Andre Hedrick
Linux Disk Certification Project Linux ATA Development

#4 lore raw
In reply to Petr Vandrovec

Whee, an IDE flamewar! :-)

People, can we get colder? Let's clarify positions without generating useless heat, ok?

1. Re multi-sector reads/writes:

Quoted 11 lines · Petr Vandrovec

If the number of requested sectors is not evenly divisible by the block count, as many full blocks as possible are transferred, followed by a final, partial block transfer. The partial block transfer shall be for n sectors, where n = remainder (sector count/block count).

And almost identical text appears on page 296, where it talks about WRITE MULTIPLE.

If you are trying to persuade us that there are devices which support ATA interface, and do not follow these paragraphs word by word, there is certainly something wrong in the ATA world...

Seems logical to me too. Imagine we have told drive to use 16 sector multi mode. Now we are trying to read 24 sectors (6 pages of 4k each):
CPU IDE
------------- ---------------
read_multiple(sect cnt=24) ->
*reading 16 sectors*
<- interrupt
give me data ->
(asm: 'rep insw')
<- <- <-16bit words with data
<- <- <- (total: 16 sectors)
*reading 8 sectors*
<- interrupt
give me data ->
<- <- <-16bit words with data
<- <- <- (total: 8 sectors)

Andre, do you think that it is _not_ ok to do multi-sector read/write ops with sector count non-divisible by programmed multisector count? Do you have or know of some existing drive which misbehaves? Do you think such drive will appear in future?

2. Re cotiguous buffer for large PIO blocks:

Quoted 12 lines · Andre Hedrick

OLD Method, with Request Page Walking:
issue atomic write 255 sectors
write sectors
interrupt_issued
walk copy of request
continue write_loop;
exit on completion and request and free local buffer.

CORRECT Method:
collect contigious physical buffer of 255 sectors
memcpy_to_local (one memcpy)
issue atomic write 255 sectors

Quoted 5 lines
	write sectors
	interrupt_issued
		update pointer
	continue write_loop;
	exit on completion and request and free local buffer.

Do I understand OLD method correctly? Example: reading 128 sectors in one transfer (assuming drive can do 128 multisector PIO):

void* page[16]; /* holds addresses of target 4k pages */
...
/* in interrupt handler: get data from IDE in PIO mode */ i=0;

while(i<16) {
    rep_insw(4096/2, page[i]);   
        /* rep_insw() in i386 pseudo-asm: 
        dx=ioport; ecx=4096/2; edi=page[i]; cld; rep insw 
        */
    i++;
}

...

I don't see flaws here, IDE will never notice that buffer is non-contiguous (except for tiny delay between insw's while i++ and i<16 get executed). Andre, can you explain what's wrong here and why you think we need CORRECT method?
--
vda