public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Pavel Emelyanov <xemul@parallels.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>,
	Xen-devel@lists.xen.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: Regression: x86/mm: new _PTE_SWP_SOFT_DIRTY bit conflicts with existing use
Date: Wed, 28 Aug 2013 08:04:25 +1000	[thread overview]
Message-ID: <1377641065.3819.137.camel@pasglop> (raw)
In-Reply-To: <CA+55aFyk6s1t92HJ5rxKZQk6dTfszmhdXz+S=MqUmM-CbMo+DQ@mail.gmail.com>

On Wed, 2013-08-21 at 09:30 -0700, Linus Torvalds wrote:
> I will be reverting the whole soft-dirty mess. I thought the
> bit-mapping games it played were already too complicated (the patch to
> pgtable-2level.h in commit 41bb3476b361 just makes me want to barf and
> came in very late, so I'm not positive about the whole soft-dirty mess
> in the first place). I really am not at all inclined to want to play
> games in this area any more. It's too damn late in the release window.

Anything that makes me try to scavenge a new PTE bits makes me
scream :-) Dunno if I'll manage to support this on power.

Also, it sort-of duplicates what KVM does for dirty tracking (for
migration, framebuffer updates, etc...). I wonder if KVM could consider
switching to this scheme, but then we end up with a user "break KVM"
file in /proc since the user can clear the refs.

I'd have been happier if the whole thing had essentially used a parallel
set of dirty tracking bitmaps (hooked up with the VMAs maybe). Add the
overhead there for as many "clients" as you want who will use the
facility and leave the PTE mostly alone basically. (I suppose we still
need to play PTE tricks to differenciate soft dirty RO vs. COW RO on
anonymous memory ?)

Cheers,
Ben.



  parent reply	other threads:[~2013-08-27 22:05 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-21 13:48 Regression: x86/mm: new _PTE_SWP_SOFT_DIRTY bit conflicts with existing use David Vrabel
2013-08-21 13:53 ` konrad wilk
2013-08-21 14:11 ` H. Peter Anvin
2013-08-21 14:19   ` Cyrill Gorcunov
2013-08-21 14:22     ` H. Peter Anvin
2013-08-21 14:29       ` Cyrill Gorcunov
2013-08-21 16:30     ` Linus Torvalds
2013-08-21 16:42       ` Cyrill Gorcunov
2013-08-21 23:05       ` Cyrill Gorcunov
2013-08-21 23:42         ` Andi Kleen
2013-08-22  5:49           ` Cyrill Gorcunov
2013-08-22  6:37             ` Minchan Kim
2013-08-22 13:12               ` Cyrill Gorcunov
2013-08-27 22:04       ` Benjamin Herrenschmidt [this message]
2013-08-21 14:12 ` Cyrill Gorcunov
2013-08-21 14:22   ` H. Peter Anvin
2013-08-21 14:53   ` Jan Beulich
2013-08-21 14:58     ` H. Peter Anvin
2013-08-21 15:42     ` Cyrill Gorcunov
2013-08-21 16:03       ` Jan Beulich
2013-08-21 16:19         ` Cyrill Gorcunov
2013-08-21 16:56           ` David Vrabel
2013-08-21 17:25             ` Cyrill Gorcunov
2013-08-21 18:17               ` Cyrill Gorcunov
2013-08-21 18:50                 ` H. Peter Anvin
2013-08-21 19:03                   ` Cyrill Gorcunov
2013-08-21 19:07                     ` Andy Lutomirski
2013-08-21 19:20                       ` Cyrill Gorcunov
2013-08-21 19:21                       ` Pavel Emelyanov
2013-08-21 23:04                     ` Linus Torvalds
2013-08-22  0:51                       ` Dave Jones
2013-08-22  5:44                         ` Cyrill Gorcunov
2013-08-22  6:41                         ` Pavel Emelyanov
2013-08-22  7:47                       ` Jan Beulich
2013-08-22  9:32                       ` David Vrabel
2013-08-22 10:16                         ` Pavel Emelyanov
2013-08-22  6:56           ` Jan Beulich
2013-08-22  7:03             ` Cyrill Gorcunov
2013-08-22  7:27               ` Jan Beulich
2013-08-22 11:27                 ` Cyrill Gorcunov
2013-08-22 11:33                   ` Jan Beulich
2013-08-22 12:18                     ` Pavel Emelyanov
2013-08-21 17:28 ` Andy Lutomirski
2013-08-22  7:54   ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1377641065.3819.137.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=Xen-devel@lists.xen.org \
    --cc=akpm@linux-foundation.org \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=gorcunov@gmail.com \
    --cc=hpa@zytor.com \
    --cc=jbeulich@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=xemul@parallels.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox