lkml.org 
[lkml]   [2000]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.050 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site