Messages in this thread | | | Subject | Re: [PATCH] Radix-tree pagecache for 2.5 | From | Momchil Velikov <> | Date | 01 Feb 2002 09:59:51 +0200 |
| |
>>>>> "Ingo" == Ingo Molnar <mingo@elte.hu> writes:
Ingo> On Fri, 1 Feb 2002, Anton Blanchard wrote:
>> There were a few solutions (from davem and ingo) to allocate a larger >> hash but with the radix patch we no longer have to worry about this.
Ingo> there is one big issue we forgot to consider.
Ingo> in the case of radix trees it's not only search depth that gets worse with
Hmm, worse, yes, the same way as page tables get "worse" with larger address spaces.
Ingo> big files. The thing i'm worried about is the 'big pagecache lock' being Ingo> reintroduced again. If eg. a database application puts lots of data into a
Yes, though I'd strongly suspect big database engines can/should/do benefit from doing their application specific caching and indexing, outperforming whatever cache implementation the OS has.
Ingo> single file (multiple gigabytes - why not), then the mapping-> i_shared_lock becomes a 'big pagecache lock' again, causing Ingo> serious SMP contention for even the read() case. Benchmarks show that it's Ingo> the distribution of locks that matters on big boxes.
So, we can use a read-write spinlock instead ->i_shared_lock, ok ?
Regards, -velco - 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/
| |