Hi Zlatko,
On 04/22/2013 02:54 PM, Zlatko Calusic wrote:
On 22.04.2013 08:43, Simon Jeons wrote:
Hi Zlatko,
On 04/22/2013 02:37 PM, Zlatko Calusic wrote:
On 12.04.2013 22:07, Zlatko Calusic wrote:
On 12.04.2013 21:40, Mel Gorman wrote:
On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic
On 22.04.2013 08:43, Simon Jeons wrote:
Hi Zlatko,
On 04/22/2013 02:37 PM, Zlatko Calusic wrote:
On 12.04.2013 22:07, Zlatko Calusic wrote:
On 12.04.2013 21:40, Mel Gorman wrote:
On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
On 09.04.2013 13:06, Mel Gorman wrote:
- The
Hi Zlatko,
On 04/22/2013 02:37 PM, Zlatko Calusic wrote:
On 12.04.2013 22:07, Zlatko Calusic wrote:
On 12.04.2013 21:40, Mel Gorman wrote:
On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
On 09.04.2013 13:06, Mel Gorman wrote:
- The only slightly negative thing I observed is
On 12.04.2013 22:07, Zlatko Calusic wrote:
On 12.04.2013 21:40, Mel Gorman wrote:
On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
On 09.04.2013 13:06, Mel Gorman wrote:
- The only slightly negative thing I observed is that with the patch
applied kswapd burns 10x - 20x more
On 12.04.2013 22:07, Zlatko Calusic wrote:
On 12.04.2013 21:40, Mel Gorman wrote:
On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
On 09.04.2013 13:06, Mel Gorman wrote:
SNIP
- The only slightly negative thing I observed is that with the patch
applied kswapd burns 10x - 20x
Hi Zlatko,
On 04/22/2013 02:37 PM, Zlatko Calusic wrote:
On 12.04.2013 22:07, Zlatko Calusic wrote:
On 12.04.2013 21:40, Mel Gorman wrote:
On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
On 09.04.2013 13:06, Mel Gorman wrote:
SNIP
- The only slightly negative thing I observed
On 22.04.2013 08:43, Simon Jeons wrote:
Hi Zlatko,
On 04/22/2013 02:37 PM, Zlatko Calusic wrote:
On 12.04.2013 22:07, Zlatko Calusic wrote:
On 12.04.2013 21:40, Mel Gorman wrote:
On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
On 09.04.2013 13:06, Mel Gorman wrote:
SNIP
-
Hi Zlatko,
On 04/22/2013 02:54 PM, Zlatko Calusic wrote:
On 22.04.2013 08:43, Simon Jeons wrote:
Hi Zlatko,
On 04/22/2013 02:37 PM, Zlatko Calusic wrote:
On 12.04.2013 22:07, Zlatko Calusic wrote:
On 12.04.2013 21:40, Mel Gorman wrote:
On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic
On 12.04.2013 22:41, Mel Gorman wrote:
On Fri, Apr 12, 2013 at 10:07:54PM +0200, Zlatko Calusic wrote:
On 12.04.2013 21:40, Mel Gorman wrote:
On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
On 09.04.2013 13:06, Mel Gorman wrote:
- The only slightly negative thing I observed
On Fri, Apr 12, 2013 at 10:07:54PM +0200, Zlatko Calusic wrote:
> On 12.04.2013 21:40, Mel Gorman wrote:
> >On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
> >>On 09.04.2013 13:06, Mel Gorman wrote:
> >>
> >>
> >>- The only slightly negative thing I observed is that with the patch
On 12.04.2013 21:40, Mel Gorman wrote:
On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
On 09.04.2013 13:06, Mel Gorman wrote:
- The only slightly negative thing I observed is that with the patch
applied kswapd burns 10x - 20x more CPU. So instead of about 15
seconds, it has
On Fri, Apr 12, 2013 at 08:40:04PM +0100, Mel Gorman wrote:
> On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
> > On 09.04.2013 13:06, Mel Gorman wrote:
> >
> >
> > - The only slightly negative thing I observed is that with the patch
> > applied kswapd burns 10x - 20x more CPU. So
On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
> On 09.04.2013 13:06, Mel Gorman wrote:
>
>
> - The only slightly negative thing I observed is that with the patch
> applied kswapd burns 10x - 20x more CPU. So instead of about 15
> seconds, it has now spent more than 4 minutes on
On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
On 09.04.2013 13:06, Mel Gorman wrote:
SNIP
- The only slightly negative thing I observed is that with the patch
applied kswapd burns 10x - 20x more CPU. So instead of about 15
seconds, it has now spent more than 4 minutes on
On Fri, Apr 12, 2013 at 08:40:04PM +0100, Mel Gorman wrote:
On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
On 09.04.2013 13:06, Mel Gorman wrote:
SNIP
- The only slightly negative thing I observed is that with the patch
applied kswapd burns 10x - 20x more CPU. So
On 12.04.2013 21:40, Mel Gorman wrote:
On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
On 09.04.2013 13:06, Mel Gorman wrote:
SNIP
- The only slightly negative thing I observed is that with the patch
applied kswapd burns 10x - 20x more CPU. So instead of about 15
seconds, it
On Fri, Apr 12, 2013 at 10:07:54PM +0200, Zlatko Calusic wrote:
On 12.04.2013 21:40, Mel Gorman wrote:
On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
On 09.04.2013 13:06, Mel Gorman wrote:
SNIP
- The only slightly negative thing I observed is that with the patch
applied
On 12.04.2013 22:41, Mel Gorman wrote:
On Fri, Apr 12, 2013 at 10:07:54PM +0200, Zlatko Calusic wrote:
On 12.04.2013 21:40, Mel Gorman wrote:
On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
On 09.04.2013 13:06, Mel Gorman wrote:
SNIP
- The only slightly negative thing I
On 09.04.2013 13:06, Mel Gorman wrote:
Posting V2 of this series got delayed due to trying to pin down an unrelated
regression in 3.9-rc where interactive performance is shot to hell. That
problem still has not been identified as it's resisting attempts to be
reproducible by a script for the
On Thu 11-04-13 10:10:44, Mel Gorman wrote:
> On Wed, Apr 10, 2013 at 03:28:32PM -0700, dormando wrote:
> > > On Tue, Apr 09, 2013 at 05:27:18PM +, Christoph Lameter wrote:
> > > > One additional measure that may be useful is to make kswapd prefer one
> > > > specific processor on a socket.
On Wed, Apr 10, 2013 at 03:28:32PM -0700, dormando wrote:
> > On Tue, Apr 09, 2013 at 05:27:18PM +, Christoph Lameter wrote:
> > > One additional measure that may be useful is to make kswapd prefer one
> > > specific processor on a socket. Two benefits arise from that:
> > >
> > > 1. Better
On Wed, Apr 10, 2013 at 03:28:32PM -0700, dormando wrote:
On Tue, Apr 09, 2013 at 05:27:18PM +, Christoph Lameter wrote:
One additional measure that may be useful is to make kswapd prefer one
specific processor on a socket. Two benefits arise from that:
1. Better use of cpu
On Thu 11-04-13 10:10:44, Mel Gorman wrote:
On Wed, Apr 10, 2013 at 03:28:32PM -0700, dormando wrote:
On Tue, Apr 09, 2013 at 05:27:18PM +, Christoph Lameter wrote:
One additional measure that may be useful is to make kswapd prefer one
specific processor on a socket. Two benefits
On 09.04.2013 13:06, Mel Gorman wrote:
Posting V2 of this series got delayed due to trying to pin down an unrelated
regression in 3.9-rc where interactive performance is shot to hell. That
problem still has not been identified as it's resisting attempts to be
reproducible by a script for the
>> I've never checked it but I would have expected kswapd to stay on the
>> same processor for significant periods of time. Have you experienced
>> problems where kswapd bounces around on CPUs within a node causing
>> workload disruption?
>
> When kswapd shares the same CPU as our main process it
> On Tue, Apr 09, 2013 at 05:27:18PM +, Christoph Lameter wrote:
> > One additional measure that may be useful is to make kswapd prefer one
> > specific processor on a socket. Two benefits arise from that:
> >
> > 1. Better use of cpu caches and therefore higher speed, less
> > serialization.
On Tue, Apr 09, 2013 at 05:27:18PM +, Christoph Lameter wrote:
> One additional measure that may be useful is to make kswapd prefer one
> specific processor on a socket. Two benefits arise from that:
>
> 1. Better use of cpu caches and therefore higher speed, less
> serialization.
>
On Tue, Apr 09, 2013 at 05:27:18PM +, Christoph Lameter wrote:
One additional measure that may be useful is to make kswapd prefer one
specific processor on a socket. Two benefits arise from that:
1. Better use of cpu caches and therefore higher speed, less
serialization.
Considering
On Tue, Apr 09, 2013 at 05:27:18PM +, Christoph Lameter wrote:
One additional measure that may be useful is to make kswapd prefer one
specific processor on a socket. Two benefits arise from that:
1. Better use of cpu caches and therefore higher speed, less
serialization.
I've never checked it but I would have expected kswapd to stay on the
same processor for significant periods of time. Have you experienced
problems where kswapd bounces around on CPUs within a node causing
workload disruption?
When kswapd shares the same CPU as our main process it causes a
One additional measure that may be useful is to make kswapd prefer one
specific processor on a socket. Two benefits arise from that:
1. Better use of cpu caches and therefore higher speed, less
serialization.
2. Reduction of the disturbances to one processor.
--
To unsubscribe from this list:
Posting V2 of this series got delayed due to trying to pin down an unrelated
regression in 3.9-rc where interactive performance is shot to hell. That
problem still has not been identified as it's resisting attempts to be
reproducible by a script for the purposes of bisection.
For those that
Posting V2 of this series got delayed due to trying to pin down an unrelated
regression in 3.9-rc where interactive performance is shot to hell. That
problem still has not been identified as it's resisting attempts to be
reproducible by a script for the purposes of bisection.
For those that
One additional measure that may be useful is to make kswapd prefer one
specific processor on a socket. Two benefits arise from that:
1. Better use of cpu caches and therefore higher speed, less
serialization.
2. Reduction of the disturbances to one processor.
--
To unsubscribe from this list:
34 matches
Mail list logo