>>> So it's basically dm calling into blk_unplug() all the time, whichWhen should dm/md set the plugged flag? It has several disks (or more dm/md layers), some of them may be plugged, some not --- furthermore, the disk queues are shared by other devices --- there may be more devices on different partitions. So the question: when do you want dm/md to set the plugged bit? Do you really want to plug the queue at the top layer and merge requests there? I changed generic_unplug_device from: spin_lock() if (plugged bit is set) unplug...; spin_unlock() to: if (plugged bit is set) { spin_lock() if (plugged bit is set) unplug...; spin_unlock() } --- I don't see anything wrong with it. At least, the change is so trivial that we can be sure that it won't have negative effect on performance. What you propose is complete rewrite of dm/md plugging mechanism to plug the queue and merge requests at upper layer --- the questions are: - what exactly you are proposing? (plugging at upper layer? lower layer? both layers? don't plug and just somehow propagate the plugged bit?) - why are you proposing that? Note that for some dm targets it would be benefical to join the requests at upper layer (dm-linear, raid1), for others (raid0, dm-snapshots) it damages performance (you merge the requests before passing them to raid0 and you chop them again to smaller pieces in raid0). Mikulas --
| Jeremy Allison | Re: [RFC] Heads up on sys_fallocate() |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Joerg Roedel | [PATCH 03/34] AMD IOMMU: add defines and structures for ACPI scanning code |
| Eric W. Biederman | [PATCH] powerpc pseries eeh: Convert to kthread API |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Natalie Protasevich | [BUG] New Kernel Bugs |
git: | |
