> I'm also sort of worried that it'll multiply up the number of syscalls (never a great idea for straight-through performance on Unix), although you may well be right about responsiveness.
I have been optimising pagecache-management for this task. This does not seem to be a problem with the version in SVN: http://code.google.com/p/pagecache-mangagement/ With this version we can use need one extra syscall after the file has been closed to drop the cache. This benchmarking was done on a Dual Core. Different CPUs might have a larger overhead, OTOH, most of the CPU legwork is going to be done in decompressing squashfs. > I doubt that we'd actually want to use pagecache-management; the copy happens in-process in order that we can display a useful progress bar, In some sense the ideal would be to have a utility that communicated with ubiquity but made use of SMP, nice and ionice. > and I don't think we'd want to kill the page cache for everything done by that process. A Python extension (or work in the Python core) to expose > posix_fadvise would be best. I have been benchmarking a few options. One is just to flush writes after several seconds. This seems fairly harmless as ubiquity would be writing to either tmpfs or /target, perhaps more ideal would be to only flush writes to /target so as to reduce the number of syscalls. Since rofs is compressed and /target is decompressed this would reduce page thrashing by a factor of more than three, and on many systems we might want to keep the entirety of rofs in memory anyway. -- Ubiquity should advise kernel to discard pages from copied files https://bugs.launchpad.net/bugs/197579 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
