Messages in this thread | | | Date | Wed, 02 Aug 2000 19:57:23 +0100 | From | Chris Quinn <> | Subject | Re: mmap() page swapping location? |
| |
Rik van Riel wrote: > > Suppose you have two database transactions, the first > of which needs to be flushed before the second one > can be flushed. > > Now suppose these transactions are on the *record* level > and two records from both transactions share one page in > memory. > > Now how are you going to flush the one transaction while > keeping back the other one? >
I've only been referring to checkpointing and keeping the file in a consistent state. At the transaction level in shadow-paging there is copying of pages for separate changes. Another possibility is ensuring the undo log distinguishes changes by transaction id, and if a transaction doesn't pan-out then roll it back; saving pages with combined changes isn't necessarily a problem. But as it happens :) as my db is rather a persistent object store and not intended for generalised db duty, I'm concentrating on the single transaction situation. This doesn't preclude concurrent transactions but if I do it they'll be in separate processes rather than threads.
> > > Also, system call and pagetable / tlb fiddling overhead is > > > quite high, especially on SMP machines. > > > > If a page is aged out of the cache and it's gonna go to disk, > > what difference does it make where (disk write optimisation > > aside)? > > None, you're right here. The overhead we would have is > not of the pagetable/tlb kind, but of the "split VMA into > dozens of smaller ones" kind. Probably just as expensive, > but something different ;) > > But at what cost? System calls and kernel operations can be > quite expensive. Doing a system call and modifying 200 bytes > of in-kernel data (holding expensive locks) probably isn't > worth it when all it saves is copying around a 50 byte database > record. > So far all I do is mmap(READ) in whole file, trap SIGSEGV and mprotect(WRITE) once the individual modified pages, finally msync()'ing at checkpoints. I wouldn't say that was spending any length of time in the kernel! I'd forgotten about the 8/1 discrepency between pages and buffers and your comments have prompted an idea for an optimisation: when computing a page diff of changes, if the result spans less than some threshold then write() out the BUFSIZE bits rather than msync()'ing whole page. Unfortunately I don't think there's a way to reset the modified bit for a mmap()'ed page.
Thanks for your comments. Chris
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |