Messages in this thread | | | Date | Fri, 27 Mar 2015 09:39:08 -0700 | From | Jeremy Allison <> | Subject | Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only) |
| |
On Fri, Mar 27, 2015 at 09:30:46AM -0700, Andrew Morton wrote: > > But from an interface perspective the behaviour you're asking for is > insane, frankly - if the kernel copied out 8k of data then pread2() > should return 8k. Otherwise there's no way for userspace to know that > the 8k copy actually happened and we have just wasted a great pile of > CPU doing a pointless memcpy.
Why would it do the copy in the first place if we asked (for example) for 16k, but only 8k was available ? Just return EAGAIN and have done with it.
> I expect that this situation (first part in cache, latter part not in > cache) is rare - for reasonably small requests the common cases will be > "all cached" and "nothing cached". So perhaps the best approach here > is for samba to add special handling for the short read, to work out > the reason for its occurrence.
We can do that, but as Volker says this is a very hot code path.
> I take it from your comments that nobody has actually wired up pread2() > into samba yet? That's a bit disturbing, because if we later want to > go and change something like this short-read behaviour, we're screwed - > it's a non back-compat userspace-visible change.
It's been done as a test, so the code exists and has run (and improved perforamance as I recall). Not much point commiting it without kernel support :-).
> And a note on cosmetics: why are we using EAGAIN here rather than > EWOULDBLOCK? They have the same numerical value, but EWOULDBLOCK is a > better name - EAGAIN says "run it again", but that won't work.
Sounds good to me !
| |