Re: mmap (was First set of OSDL Shared Mem scalability results, some wierdness ...

On Fri, Oct 15, 2004 at 01:09:01PM -0700, Sean Chittenden wrote:
[snip]
> >
> > This ultimately depends on two things: how much time is spent copying
> > buffers around in kernel memory, and how much advantage can be gained
> > by freeing up the memory used by the backends to store the
> > backend-local copies of the disk pages they use (and thus making that
> > memory available to the kernel to use for additional disk buffering).
>
> Someone on IRC pointed me to some OSDL benchmarks, which broke down
> where time is being spent. Want to know what the most expensive part
> of PostgreSQL is? *drum roll*
>
> http://khack.osdl.org/stp/297960/profile/DBT_2_Profile-tick.sort
>
> 3967393 total 1.7735
> 2331284 default_idle 36426.3125
> 825716 do_sigaction 1290.1813
> 133126 __copy_from_user_ll 1040.0469
> 97780 __copy_to_user_ll 763.9062
> 43135 finish_task_switch 269.5938
> 30973 do_anonymous_page 62.4456
> 24175 scsi_request_fn 22.2197
> 23355 __do_softirq 121.6406
> 17039 __wake_up 133.1172
> 16527 __make_request 10.8730
> 9823 try_to_wake_up 13.6431
> 9525 generic_unplug_device 66.1458
> 8799 find_get_page 78.5625
> 7878 scsi_end_request 30.7734
>
> Copying data to/from userspace and signal handling!!!! Let's hear it
> for the need for mmap(2)!!! *crowd goes wild*
>
[snip]

I know where the do_sigaction is coming from in this particular case.
Manfred Spraul tracked it to a pair of pgsignal calls in libpq.
Commenting out those two calls out virtually eliminates do_sigaction from
the kernel profile for this workload. I've lost track of the discussion
over the past year, but I heard a rumor that it was finally addressed to
some degree. I did understand it touched on a lot of other things, but
can anyone summarize where that discussion has gone?

Mark