On Tue, 1 Aug 2000, Chris Quinn wrote:
> 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'm not sure granularity comes into it(?)
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?
> > 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 ;)
> > 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!
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.
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