On Thu, Jan 23, 2014 at 04:15:55PM +0400, Cyrill Gorcunov wrote:
> On Thu, Jan 23, 2014 at 02:36:06PM +0400, Cyrill Gorcunov wrote:
> > > The test case passes with this patch applied to 3.13 so that appears
> > > to confirm that this is related to VM_SOFTDIRTY preventing merges.
> > >
On Thu, Jan 23, 2014 at 02:36:06PM +0400, Cyrill Gorcunov wrote:
> > The test case passes with this patch applied to 3.13 so that appears
> > to confirm that this is related to VM_SOFTDIRTY preventing merges.
> > Unfortunately I did not have slabinfo tracking enabled to double check
> > the number
On Thu, Jan 23, 2014 at 09:55:41AM +, Mel Gorman wrote:
> On Thu, Jan 23, 2014 at 02:33:25AM +0400, Cyrill Gorcunov wrote:
> > On Wed, Jan 22, 2014 at 11:19:28PM +0400, Cyrill Gorcunov wrote:
> > > > commit. Test case was simple -- try and open the large file described in
> > > > the bug. I
On Thu, Jan 23, 2014 at 02:33:25AM +0400, Cyrill Gorcunov wrote:
> On Wed, Jan 22, 2014 at 11:19:28PM +0400, Cyrill Gorcunov wrote:
> > > commit. Test case was simple -- try and open the large file described in
> > > the bug. I did not investigate the patch itself as I'm just reporting
> > > the
On Thu, Jan 23, 2014 at 02:33:25AM +0400, Cyrill Gorcunov wrote:
> On Wed, Jan 22, 2014 at 11:19:28PM +0400, Cyrill Gorcunov wrote:
> > > commit. Test case was simple -- try and open the large file described in
> > > the bug. I did not investigate the patch itself as I'm just reporting
> > > the
On Thu, Jan 23, 2014 at 02:33:25AM +0400, Cyrill Gorcunov wrote:
On Wed, Jan 22, 2014 at 11:19:28PM +0400, Cyrill Gorcunov wrote:
commit. Test case was simple -- try and open the large file described in
the bug. I did not investigate the patch itself as I'm just reporting
the results of
On Thu, Jan 23, 2014 at 02:33:25AM +0400, Cyrill Gorcunov wrote:
On Wed, Jan 22, 2014 at 11:19:28PM +0400, Cyrill Gorcunov wrote:
commit. Test case was simple -- try and open the large file described in
the bug. I did not investigate the patch itself as I'm just reporting
the results of
On Thu, Jan 23, 2014 at 09:55:41AM +, Mel Gorman wrote:
On Thu, Jan 23, 2014 at 02:33:25AM +0400, Cyrill Gorcunov wrote:
On Wed, Jan 22, 2014 at 11:19:28PM +0400, Cyrill Gorcunov wrote:
commit. Test case was simple -- try and open the large file described in
the bug. I did not
On Thu, Jan 23, 2014 at 02:36:06PM +0400, Cyrill Gorcunov wrote:
The test case passes with this patch applied to 3.13 so that appears
to confirm that this is related to VM_SOFTDIRTY preventing merges.
Unfortunately I did not have slabinfo tracking enabled to double check
the number of
On Thu, Jan 23, 2014 at 04:15:55PM +0400, Cyrill Gorcunov wrote:
On Thu, Jan 23, 2014 at 02:36:06PM +0400, Cyrill Gorcunov wrote:
The test case passes with this patch applied to 3.13 so that appears
to confirm that this is related to VM_SOFTDIRTY preventing merges.
Unfortunately I did
On Wed, Jan 22, 2014 at 11:52:15AM -0800, Andrew Morton wrote:
> On Wed, 22 Jan 2014 19:08:16 + Mel Gorman wrote:
>
> > X-related junk is there was because I was using a headless server and
> > xinit directly to launch gimp to reproduce the bug.
>
> I've never done this. Can you share the
On Wed, Jan 22, 2014 at 10:09:10PM -0800, Andrew Morton wrote:
> > >
> > > That being said, this could cause vma blowups for programs that are
> > > actually using this thing.
> >
> > Hi Andy, indeed, this could happen. The easiest way is to ignore softdirty
> > bit
> > when we're trying to
On Thu, 23 Jan 2014 09:59:06 +0400 Cyrill Gorcunov wrote:
> On Wed, Jan 22, 2014 at 02:45:53PM -0800, Andy Lutomirski wrote:
> > >
> > > Thus when user space application track memory changes now it can
> > > detect if
> > > vma area is renewed.
> >
> > Presumably some path is
On Wed, Jan 22, 2014 at 02:45:53PM -0800, Andy Lutomirski wrote:
> >
> > Thus when user space application track memory changes now it can detect
> > if
> > vma area is renewed.
>
> Presumably some path is failing to set VM_SOFTDIRTY, thus preventing mms
> from being merged.
>
>
On 01/22/2014 11:08 AM, Mel Gorman wrote:
> Cyrill,
>
> Gimp is broken due to a kernel bug included in 3.12. It cannot open
> large files without failing memory allocations due to exceeding
> vm.max_map_count. The relevant bugzilla entries are
>
>
On Wed, Jan 22, 2014 at 11:19:28PM +0400, Cyrill Gorcunov wrote:
> > commit. Test case was simple -- try and open the large file described in
> > the bug. I did not investigate the patch itself as I'm just reporting
> > the results of the bisection. If I had to guess, I'd say that VMA
> > merging
On Wed, 22 Jan 2014 19:08:16 + Mel Gorman wrote:
> X-related junk is there was because I was using a headless server and
> xinit directly to launch gimp to reproduce the bug.
I've never done this. Can you share the magic recipe for running an X
app in this way?
Thanks.
--
To unsubscribe
On Wed, Jan 22, 2014 at 07:08:16PM +, Mel Gorman wrote:
> Cyrill,
>
> Gimp is broken due to a kernel bug included in 3.12. It cannot open
> large files without failing memory allocations due to exceeding
> vm.max_map_count. The relevant bugzilla entries are
>
>
Cyrill,
Gimp is broken due to a kernel bug included in 3.12. It cannot open
large files without failing memory allocations due to exceeding
vm.max_map_count. The relevant bugzilla entries are
https://bugzilla.kernel.org/show_bug.cgi?id=67651
https://bugzilla.gnome.org/show_bug.cgi?id=719619#c0
Cyrill,
Gimp is broken due to a kernel bug included in 3.12. It cannot open
large files without failing memory allocations due to exceeding
vm.max_map_count. The relevant bugzilla entries are
https://bugzilla.kernel.org/show_bug.cgi?id=67651
https://bugzilla.gnome.org/show_bug.cgi?id=719619#c0
On Wed, Jan 22, 2014 at 07:08:16PM +, Mel Gorman wrote:
Cyrill,
Gimp is broken due to a kernel bug included in 3.12. It cannot open
large files without failing memory allocations due to exceeding
vm.max_map_count. The relevant bugzilla entries are
On Wed, 22 Jan 2014 19:08:16 + Mel Gorman mgor...@suse.de wrote:
X-related junk is there was because I was using a headless server and
xinit directly to launch gimp to reproduce the bug.
I've never done this. Can you share the magic recipe for running an X
app in this way?
Thanks.
--
To
On Wed, Jan 22, 2014 at 11:19:28PM +0400, Cyrill Gorcunov wrote:
commit. Test case was simple -- try and open the large file described in
the bug. I did not investigate the patch itself as I'm just reporting
the results of the bisection. If I had to guess, I'd say that VMA
merging has been
On 01/22/2014 11:08 AM, Mel Gorman wrote:
Cyrill,
Gimp is broken due to a kernel bug included in 3.12. It cannot open
large files without failing memory allocations due to exceeding
vm.max_map_count. The relevant bugzilla entries are
https://bugzilla.kernel.org/show_bug.cgi?id=67651
On Wed, Jan 22, 2014 at 02:45:53PM -0800, Andy Lutomirski wrote:
Thus when user space application track memory changes now it can detect
if
vma area is renewed.
Presumably some path is failing to set VM_SOFTDIRTY, thus preventing mms
from being merged.
That being said,
On Thu, 23 Jan 2014 09:59:06 +0400 Cyrill Gorcunov gorcu...@gmail.com wrote:
On Wed, Jan 22, 2014 at 02:45:53PM -0800, Andy Lutomirski wrote:
Thus when user space application track memory changes now it can
detect if
vma area is renewed.
Presumably some path is
On Wed, Jan 22, 2014 at 10:09:10PM -0800, Andrew Morton wrote:
That being said, this could cause vma blowups for programs that are
actually using this thing.
Hi Andy, indeed, this could happen. The easiest way is to ignore softdirty
bit
when we're trying to merge vmas and set
On Wed, Jan 22, 2014 at 11:52:15AM -0800, Andrew Morton wrote:
On Wed, 22 Jan 2014 19:08:16 + Mel Gorman mgor...@suse.de wrote:
X-related junk is there was because I was using a headless server and
xinit directly to launch gimp to reproduce the bug.
I've never done this. Can you
28 matches
Mail list logo
