Re: mmap (was First set of OSDL Shared Mem scalability results, some wierdness ... - Mailing list pgsql-performance

From Mark Wong
Subject Re: mmap (was First set of OSDL Shared Mem scalability results, some wierdness ...
Date
Msg-id 20041015133947.A9225@osdl.org
Whole thread Raw
In response to Re: mmap (was First set of OSDL Shared Mem scalability results, some wierdness ...  (Sean Chittenden <sean@chittenden.org>)
Responses Re: mmap (was First set of OSDL Shared Mem scalability results, some wierdness ...
List pgsql-performance
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

pgsql-performance by date:

Previous
From: Josh Berkus
Date:
Subject: Re: [Testperf-general] Re: First set of OSDL Shared Memscalability results, some wierdness ...
Next
From: Doug Y
Date:
Subject: Re: Tuning shared_buffers with ipcs ?