On Mon, 15 Oct 2007 16:13:15 -0400 Rik van Riel <riel@redhat.com> wrote:Gee. Expect the unexpected ;) One problem might be when kjournald is doing its ordered-mode data writeback at the start of commit. That writeout will now be higher-priority and might impact other tasks which are doing synchronous file overwrites (ie: no commits) or O_DIRECT reads or writes or just plain old reads. If the aggregate number of seeks over the long term is the same as before then of course the overall throughput should be the same, in which case the impact might only be upon latency. However if for some reason the total number of seeks is increased then there will be throughput impacts as well. So as a starting point I guess one could set up a copy-a-kernel-tree-in-a-loop running in the background and then see what impact that has upon a large-linear-read, upon a read-a-different-kernel-tree and upon some database-style multithreaded O_DIRECT reader/overwriter. -
| Greg Kroah-Hartman | [PATCH 002/196] Chinese: rephrase English introduction in HOWTO |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Andrew Morton | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
| Greg KH | Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| Arjan van de Ven | Re: [GIT]: Networking |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Jarek Poplawski | Re: [BUG] New Kernel Bugs |
