On Thu, Aug 27, 2015 at 05:09:21PM +0200, Thomas Gleixner wrote:
> On Thu, 27 Aug 2015, Steven Rostedt wrote:
> > On Thu, 27 Aug 2015 15:18:49 +0200
> > Frederic Weisbecker wrote:
> >
> > > On Wed, Aug 26, 2015 at 04:45:44PM -0700, Hideaki Kimura wrote:
> > > > I totally agree that this is not a
On Thu, 27 Aug 2015, Steven Rostedt wrote:
> On Thu, 27 Aug 2015 15:18:49 +0200
> Frederic Weisbecker wrote:
>
> > On Wed, Aug 26, 2015 at 04:45:44PM -0700, Hideaki Kimura wrote:
> > > I totally agree that this is not a perfect solution. If there are 10x more
> > > cores and sockets, just the ato
On Thu, 27 Aug 2015 15:18:49 +0200
Frederic Weisbecker wrote:
> On Wed, Aug 26, 2015 at 04:45:44PM -0700, Hideaki Kimura wrote:
> > I totally agree that this is not a perfect solution. If there are 10x more
> > cores and sockets, just the atomic fetch_add might be too expensive.
> >
> > However,
On Wed, Aug 26, 2015 at 04:45:44PM -0700, Hideaki Kimura wrote:
> I totally agree that this is not a perfect solution. If there are 10x more
> cores and sockets, just the atomic fetch_add might be too expensive.
>
> However, it's comparatively/realistically the best thing we can do without
> any d
On 08/26/2015 04:13 PM, Frederic Weisbecker wrote:
On Wed, Aug 26, 2015 at 03:53:26PM -0700, Hideaki Kimura wrote:
Sure, let me elaborate.
Executive summary:
Yes, enabling a process-wide timer in such a large machine is not wise, but
sometimes users/applications cannot avoid it.
The issue
On Wed, Aug 26, 2015 at 03:53:26PM -0700, Hideaki Kimura wrote:
> Sure, let me elaborate.
>
> Executive summary:
> Yes, enabling a process-wide timer in such a large machine is not wise, but
> sometimes users/applications cannot avoid it.
>
>
> The issue was observed actually not in a database
Sure, let me elaborate.
Executive summary:
Yes, enabling a process-wide timer in such a large machine is not
wise, but sometimes users/applications cannot avoid it.
The issue was observed actually not in a database itself but in a common
library it links to; gperftools.
The database itsel
On Wed, 2015-08-26 at 19:08 +0200, Oleg Nesterov wrote:
> On 08/26, Jason Low wrote:
> >
> > Hi Andrew,
> >
> > On Tue, 2015-08-25 at 20:27 -0700, Andrew Morton wrote:
> > > On Tue, 25 Aug 2015 20:17:45 -0700 Jason Low wrote:
> > >
> > > > When running a database workload on a 16 socket machine, t
On 08/26, Jason Low wrote:
>
> Hi Andrew,
>
> On Tue, 2015-08-25 at 20:27 -0700, Andrew Morton wrote:
> > On Tue, 25 Aug 2015 20:17:45 -0700 Jason Low wrote:
> >
> > > When running a database workload on a 16 socket machine, there were
> > > scalability issues related to itimers.
> > >
> > > Commi
Hi Andrew,
On Tue, 2015-08-25 at 20:27 -0700, Andrew Morton wrote:
> On Tue, 25 Aug 2015 20:17:45 -0700 Jason Low wrote:
>
> > When running a database workload on a 16 socket machine, there were
> > scalability issues related to itimers.
> >
> > Commit 1018016c706f addressed the issue with the
On Tue, 25 Aug 2015 20:17:45 -0700 Jason Low wrote:
> When running a database workload on a 16 socket machine, there were
> scalability issues related to itimers.
>
> Commit 1018016c706f addressed the issue with the thread_group_cputimer
> spinlock taking up a significant portion of total run ti
When running a database workload on a 16 socket machine, there were
scalability issues related to itimers.
Commit 1018016c706f addressed the issue with the thread_group_cputimer
spinlock taking up a significant portion of total run time.
This patch series address the other issue where a lot of ti
12 matches
Mail list logo
