Messages in this thread | | | Date | Fri, 15 Jul 2005 17:23:47 +0900 | From | Tejun Heo <> | Subject | Re: [rfc patch 2/2] direct-io: remove address alignment check |
| |
Badari Pulavarty wrote: > Tejun Heo wrote: > >> Daniel McNeil wrote: >> >>> This patch relaxes the direct i/o alignment check so that user addresses >>> do not have to be a multiple of the device block size. >>> >>> I've done some preliminary testing and it mostly works on an ext3 >>> file system on a ide disk. I have seen trouble when the user address >>> is on an odd byte boundary. Sometimes the data is read back incorrectly >>> on read and sometimes I get these kernel error messages: >>> hda: dma_timer_expiry: dma status == 0x60 >>> hda: DMA timeout retry >>> hda: timeout waiting for DMA >>> hda: status error: status=0x58 { DriveReady SeekComplete >>> DataRequest } >>> ide: failed opcode was: unknown >>> hda: drive not ready for command >>> >>> Doing direct-io with user addresses on even, non-512 boundaries appears >>> to be working correctly. >>> >>> Any additional testing and/or comments welcome. >>> >> >> Hi, Daniel. >> >> I don't think the change is a good idea. We may be able to relax >> alignment contraints on some hardware to certain levels, but IMHO it >> will be very difficult to verify. All internal block IO code follows >> strict block boundary alignment. And as raw IOs (especially unaligned >> ones) aren't very common operations, they won't get tested much. Then >> when some rare (probably not an open source one) application uses it >> on some rare buggy hardware, it may cause *very* strange things. >> >> Also, I don't think it will improve application programmer's >> convenience. As each hardware employs different DMA alignemnt, we >> need to implement a way to export the alignment to user space and >> enforce it. So, in the end, user application must do aligned >> allocation accordingly. Just following block boundary will be easier. >> >> I don't know why you wanna relax the alignment requirement, but >> wouldn't it be easier to just write/use block-aligned allocator for >> such buffers? It will even make the program more portable. >> > > I can imagine a reason for relaxing the alignment. I keep getting asked > whether we can do "O_DIRECT mount option". Database folks wants to > make sure all the access to files in a given filesystem are O_DIRECT > (whether they are accessing or some random program like ftp, scp, cp > are acessing them). This was mainly to ensure that buffered accesses to > the file doesn't polute the pagecache (while database is using O_DIRECT > access). Seems like a logical request, but not easy to do :( > > Thanks, > Badari
I don't know much about VM, but, if that's necessary, I think that limiting pagecache size per mounted fs (or by some other applicable category) is easier/more complete approach. After all, you cannot mmap w/ O_DIRECT and many programs (gcc, ld come to mind) mmap large part of their memory usage.
Thanks.
-- tejun - 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/
| |