lkml.org 
[lkml]   [2005]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-07-15 10:28    [W:0.077 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site