Ulrich Drepper a écrit :
Eric Dumazet wrote:
Database workload, where the user multi threaded app is constantly
accessing GBytes of data, so L2 cache hit is very small. If you want to
oprofile it, with say a CPU_CLK_UNHALTED:5000 event, then find_vma() is
in the top 5.
We did have a workload with lots of Java and databases at some point
when many VMAs were the issue. I brought this up here one, maybe two
years ago and I think Blaisorblade went on and looked into avoiding VMA
splits by having mprotect() not split VMAs and instead store the flags
in the page table somewhere. I don't remember the details.
Nothing came out of this but if this is possible it would be yet another
way to avoid mmap_sem locking, right?
I was speaking about oprofile needs, that may interfere with target process
needs, since oprofile calls find_vma() on the target process mm and thus zap
its mmap_cache.
oprofile is yet another mmap_sem user, but also a mmap_cache destroyer.
We could at least have a separate cache, only for oprofile.
If done correctly we might avoid taking mmap_sem when the same vm_area_struct
contains EIP/RIP snapshots.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
