[lkml]   [1996]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: writev() "bug"
Alan Cox writes:
> Large numbers of iovecs would mean putting a lot of kernel changes in
> as we just shove a kernel space mapped image of the iovec list on the
> stack. I've not got any applications that have moaned at eight so I feel
> reasonably happy with this at the moment.

Hrm, okay. I didn't realize it would be difficult to change this. At
any rate, I *have* had problems with eight: sendpage 7a tries to write
out 11 items using writev(). For some reason, it worked when I was
running 1.2.13, but broke when I upgraded to pre2.0.9. I can't figure
out *why* it worked, since as far as I can tell 1.2.13 didn't even
support writev(). (At least, I couldn't find any code in the kernel
to handle it. I'm still using the same libc version, 5.2.18, so
unless libc has adaptive code that emulates writev() for older
kernels, I can't find the code that would have implemented it.)

I think that there is still a lot of SunOS-centric code out there that
will blindly assume it can write up to 16 iov's in one call. For that
reason, I don't think Linux should go smaller than that unless
absolutely necessary. Why is it any harder to shove 64 bytes onto the
stack (8 iov structs) than 128 bytes (16 iov structs)? I wouldn't
think you would run into problems until you get much larger and start
running into the VM page size.


 \ /
  Last update: 2005-03-22 13:37    [W:0.033 / U:1.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site