linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@transmeta.com>
To: Kanoj Sarcar <kanoj@google.engr.sgi.com>
Cc: manfreds@colorfullife.com, sct@redhat.com, andrea@suse.de,
	viro@math.psu.edu, linux-mm@kvack.org,
	linux-kernel@vger.rutgers.edu
Subject: Re: [PATCH] kanoj-mm17-2.3.21 kswapd vma scanning protection
Date: Fri, 15 Oct 1999 15:04:33 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.10.9910151459320.852-100000@penguin.transmeta.com> (raw)
In-Reply-To: <199910152139.OAA57321@google.engr.sgi.com>


On Fri, 15 Oct 1999, Kanoj Sarcar wrote:
> 
> This basically means that you are overloading the page_table_lock to do 
> the work of the vmlist_lock in my patch. Thus vmlist_modify_lock/
> vmlist_access_lock in my patch could be changed in mm.h to grab the 
> page_table_lock. As I mentioned before, moving to a spinlock to 
> protect the vma chain will need some changes to the vmscan.c code.

Agreed. 

> The reason I think most people suggested a different lock, namely vmlist_lock,
> is to reduce contention on the page_table_lock, so that all the other
> paths like mprotect/mlock/mmap/munmap do not end up grabbing the
> page_table_lock which is grabbed in the fault path.

There can be no contention on the page_table_lock in the absense of the
page stealer. The reason is simple: every single thing that gets the page
table lock has already gotten the mm lock beforehand, and as such
contention is never an issue.

Contention _only_ occurs for the specific case when somebody is scanning
the page tables in order to free up pages. And at that point it's not
contention any more, at that point it is the thing that protects us from
bad things happening.

As such, the hold time of the spinlock is entirely immaterial, and
coalescing the page table lock and the vmlist lock does not increase
contention, it only decreases the number of locks you have to get. At
least as far as I can see.

> Let me know how you want me to rework the patch. Imo, we should keep
> the macros vmlist_modify_lock/vmlist_access_lock, even if we do
> decide to overload the page table lock.

Don't think of it as overloading the page table lock. Notice how the page
table lock really isn't a page table lock - it really is just "protection
against vmscan", and it's misnamed mainly because the only part we
protected was the page tables (which isn't enough). 

So think of it as a fix to the current protection, and as that fix makes
it protect more than just the page tables (makes it protect everything
that is required), the name should also change.

		Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

  reply	other threads:[~1999-10-15 22:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-10-15  0:06 Kanoj Sarcar
1999-10-15 11:58 ` Manfred Spraul
1999-10-15 16:38   ` Kanoj Sarcar
1999-10-15 18:26     ` Manfred Spraul
1999-10-15 18:43       ` Kanoj Sarcar
1999-10-15 20:47         ` Manfred Spraul
1999-10-15 21:13           ` Kanoj Sarcar
1999-10-15 21:24             ` Linus Torvalds
1999-10-15 21:39               ` Kanoj Sarcar
1999-10-15 22:04                 ` Linus Torvalds [this message]
1999-10-15 22:32                   ` Kanoj Sarcar
1999-10-15 23:16               ` Manfred Spraul
1999-10-16  0:44                 ` Linus Torvalds
1999-10-18 19:45 ` Kanoj Sarcar
1999-10-18 20:02   ` Linus Torvalds

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=Pine.LNX.4.10.9910151459320.852-100000@penguin.transmeta.com \
    --to=torvalds@transmeta.com \
    --cc=andrea@suse.de \
    --cc=kanoj@google.engr.sgi.com \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    --cc=manfreds@colorfullife.com \
    --cc=sct@redhat.com \
    --cc=viro@math.psu.edu \
    /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