Unexpected splice "always copy" behavior observed
in [Kernel]
|
From: Miklos Szeredi on 19 May 2010 11:40 On Wed, 19 May 2010, Linus Torvalds wrote: > Btw, since you apparently have a real case - is the "splice to file" > always just an append? IOW, if I'm not right in assuming that the only > sane thing people would reasonable care about is "append to a file", then > holler now. Virtual machines might reasonably need this for splicing to a disk image. Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 19 May 2010 11:40 On Thu, 20 May 2010, Nick Piggin wrote: > > Well I mean a full invalidate -- invalidate_mapping_pages -- so there is > literally no pagecache there at all. Umm. That won't work. Think mapped pages. You can't handle them atomically, so somebody will page-fault them in. So you'd have to have a "invalidate_and_replace()" to do it atomically while holding the mapping spinlock or something. And WHAT IS THE POINT? That will be about a million times slower than just doing the effing copy in the first place! Memory copies are _not_ slow. Not compared to taking locks and doing TLB invalidates. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 19 May 2010 11:40 On Wed, 19 May 2010, Miklos Szeredi wrote: > > Another limitation I found while splicing from one file to another is > that stealing from the source file's page cache does not always > succeed. This turned out to be because of a reference from the lru > cache for freshly read pages. I'm not sure how this could be fixed. It should be fixed by saying "you can't always just move the page". Copying is not evil. Complexity to avoid copies is evil. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Steven Rostedt on 19 May 2010 11:50 On Wed, 2010-05-19 at 17:33 +0200, Miklos Szeredi wrote: > On Wed, 19 May 2010, Linus Torvalds wrote: > > Btw, since you apparently have a real case - is the "splice to file" > > always just an append? IOW, if I'm not right in assuming that the only > > sane thing people would reasonable care about is "append to a file", then > > holler now. > > Virtual machines might reasonably need this for splicing to a disk > image. This comes down to balancing speed and complexity. Perhaps a copy is fine in this case. I'm concerned about high speed tracing, where we are always just taking pages from the trace ring buffer and appending them to a file or sending them off to the network. The slower this is, the more likely you will lose events. If the "move only on append to file" is easy to implement, I would really like to see that happen. The speed of splicing a disk image for a virtual machine only impacts the patience of the user. The speed of splicing tracing output, impacts how much you can trace without losing events. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Nick Piggin on 19 May 2010 11:50
On Wed, May 19, 2010 at 08:30:10AM -0700, Linus Torvalds wrote: > > > On Thu, 20 May 2010, Nick Piggin wrote: > > > > Well I mean a full invalidate -- invalidate_mapping_pages -- so there is > > literally no pagecache there at all. > > Umm. That won't work. Think mapped pages. You can't handle them > atomically, so somebody will page-fault them in. > > So you'd have to have a "invalidate_and_replace()" to do it atomically > while holding the mapping spinlock or something. > > And WHAT IS THE POINT? That will be about a million times slower than > just doing the effing copy in the first place! > > Memory copies are _not_ slow. Not compared to taking locks and doing TLB > invalidates. No I never thought it would be a good idea to try to avoid all races or anything. Obviously some cases *cannot* be easily invalidated, if there is a ref on the page or whatever, so the fallback code has to be there anyway. So you would just invalidate and try to insert your page. 99.something% of the time it will work fine. If the insert fails, fall back to copying. And hey you *may* even want a heuristic that avoids trying to invalidate if the page is mapped, due to cost of TLB flushing and faulting etc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |