Hi Rik,
Rik van Riel wrote:
> There's only one big problem with this. The database will
> have to do this "locking" on PAGE granularity, and not on
> object granularity.
I'm not really after locking as such, just a way to avoid altering the underlying file until the right moment. I can't see much difference performance wise whether a page is swapped out to the swap device or to its originating file. I'm not sure granularity comes into it(?)
>
> 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)?
>
> Maybe it would be better to copy the "pinned" database
> data to separate memory and copy it back to the mmap()ed
> region later, when you can flush it out?
I like to think such copying is avoidable ... and that's what I'm aiming for!
>
> (so you do more explicit management on a per-object basis,
> you will suffer the cost of copying objects around, but that
> is most likely cheaper than working on the page granularity
> and doing lots of system calls and expensive TLB operations)
The main problem I see with MAP_SWAP is when a modified page is in swap and must be brought back in simply to write out again for an msync()/munmap(). This can of course only occur at times of memory contention and isn't the norm.
Looking at the kernel code comtemplating changing it to handle this makes my head hurt! Whether I attempt it depends on the comments people care to make about feasibility- but I do think MAP_SWAP would be a boon to the checkpointing operation of a database app!
thanks,
chris
>
> regards,
>
> Rik
> --
> "What you're running that piece of shit Gnome?!?!"
> -- Miguel de Icaza, UKUUG 2000
>
> http://www.conectiva.com/ http://www.surriel.com/
-
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/
This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:06 EST