![]() | |||||||||||||
Messages in this thread |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2007-04-05 06:57 [from the cache] ©2003-2008 | |||||||||||||