Re: MMAP Buffers

Tom Lane <tgl@sss.pgh.pa.us> Sunday 17 April 2011 01:35:45
> Radosław Smogura <rsmogura@softperience.eu> writes:
> > No, no, no :) I wanted to do this, but from above reason I skipped it. I
> > swap VM pages, I do remap, in place where the shared buffer was I put
> > mmaped page, and in place where mmaped page was I put shared page (in
> > certain cases, which should be optimized by e. g. read for update, for
> > initial read of page in process I directly points to shared buffer), it
> > can be imagined as I affects TLB. This what I call "VM swap" is
> > remapping, so I don't change pointers, I change only where this pointers
> > points in physical memory, preserving same pointer in Virtual Memory.
> 
> ... Huh?  Are you saying that you ask the kernel to map each individual
> shared buffer separately?  I can't believe that's going to scale to
> realistic applications.
> 
>             regards, tom lane

No, I do 
mrempa(mmap_buff_A, MAP_FIXED, temp); 
mremap(shared_buff_Y, MAP_FIXED, mmap_buff_A), 
mrempa(tmp, MAP_FIXED, mmap_buff_A). 

This is this additional overhead - and may have some disadvantages. All 
regions SysV / Posix MMAP are mapped before. 

I couldn't believe too, but as I done some work about read, I was in dead 
corner: 
1. Create Read Before Buffer (connect with XLOG) that will store each page 
before modification (page should be flushed and synced to log)
2. Rewrite whole db to repoint pointers or similar stuff (I done few steps for 
this).
3. Or find something different. 

I couldn't believe too, it's way I still work on it. I saw it gains speed for 
few simple updates. I'm not quite sure why it gets it. I only may think it  
was from "pre update reads". But full checks will go after some good point of 
updates.

Regards,
Radek