linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@bonn-fries.net>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Rik van Riel <riel@conectiva.com.br>,
	Hugh Dickins <hugh@veritas.com>,
	dmccr@us.ibm.com,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, Robert Love <rml@tech9.net>,
	mingo@redhat.com, Andrew Morton <akpm@zip.com.au>,
	manfred@colorfullife.com, wli@holomorphy.com
Subject: Re: [RFC] Page table sharing
Date: Wed, 20 Feb 2002 15:10:20 +0100	[thread overview]
Message-ID: <E16dXRt-0001Lo-00@starship.berlin> (raw)
In-Reply-To: <Pine.LNX.4.33.0202190923390.26476-100000@home.transmeta.com>

On February 19, 2002 06:29 pm, Linus Torvalds wrote:
> On Tue, 19 Feb 2002, Daniel Phillips wrote:
> > Linus Torvalds wrote:
> > > At that point you might as well make the TLB shootdown global (ie you
> > > keep track of a mask of CPU's whose TLB's you want to kill, and any pmd 
> > > that has count > 1 just makes that mask be "all CPU's").
> >
> > How do we know when to do the global tlb flush?
> 
> See above.
> 
> Basically, the algorithm is:
> 
> 	invalidate_cpu_mask = 0;
> 
> 	.. for each page swapped out ..
> 
> 		pte = ptep_get_and_clear(ptep);
> 		save_pte_and_mm(pte_page(pte));
> 		mask = mm->cpu_vm_mask;
> 		if (page_count(pmd_page) > 1)
> 			mask = ~0UL;
> 		invalidate_cpu_mask |= mask;
> 
> and then at the end you just do
> 
> 	flush_tlb_cpus(invalidate_cpu_mask);
> 	for_each_page_saved() {
> 		free_page(page);
> 	}

Silence is the sound of me researching tlb shootdowns, ipi's and the like, to 
prepare for doing this work.  We don't have a flush_tlb_cpus at the moment, 
however it doesn't look hard to write.  We don't have save_pte_and_mm either, 
and it seems that it's only valid in the case the page table use count is 
one, otherwise we need a page table reverse mapping scheme, a practical and 
worthwhile optimization, but not essential to get something working.

<rant>
This topic is very poorly covered in terms of background material.  What 
information there is seems to be scattered through various Intel manuals or 
old lkml posts, or tucked away in professional seminars and higher level 
computer engineering courses.  Once again we have a situation where hackers 
are divided into two groups: those that know the material and haven't got 
time or inclination to document it, or those that don't know it and aren't 
willling to admit that for fear of seeming ignorant.
</rant>

Davem has done a nice job of documenting the existing tlb operations, what's 
missing is the information required to construct new ones.  Can anybody out 
there point me to a primer, or write one?

Looking at the current try_to_swap_out code I see only a local invalidate, 
flush_tlb_page(vma, address), why is that?  How do we know that this mm could 
not be in context on another cpu?

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

  parent reply	other threads:[~2002-02-20 14:10 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.33.0202162219230.8326-100000@home.transmeta.com>
2002-02-17 19:39 ` Daniel Phillips
2002-02-17 20:16   ` Daniel Phillips
2002-02-17 22:16   ` Hugh Dickins
2002-02-18  1:35     ` Daniel Phillips
2002-02-18  8:09       ` Hugh Dickins
2002-02-18  9:41         ` Daniel Phillips
2002-02-18 11:32           ` Daniel Phillips
2002-02-18 19:04           ` Hugh Dickins
2002-02-18 23:37             ` Daniel Phillips
2002-02-19  0:56               ` Linus Torvalds
2002-02-19  1:22                 ` Rik van Riel
2002-02-19  1:29                   ` Daniel Phillips
2002-02-19  1:48                   ` Linus Torvalds
2002-02-19  1:53                     ` Rik van Riel
2002-02-19  2:05                       ` Linus Torvalds
2002-02-19  2:22                         ` Daniel Phillips
2002-02-19  2:35                           ` Linus Torvalds
2002-02-19  2:55                             ` Daniel Phillips
2002-02-19  3:11                             ` Daniel Phillips
2002-02-19  3:22                             ` Linus Torvalds
2002-02-19  3:45                               ` Daniel Phillips
2002-02-19 17:29                                 ` Linus Torvalds
2002-02-19 18:11                                   ` Hugh Dickins
2002-02-20 14:18                                     ` Daniel Phillips
2002-02-20 15:30                                       ` Hugh Dickins
2002-02-20 14:10                                   ` Daniel Phillips [this message]
2002-02-20 14:38                                     ` Hugh Dickins
2002-02-20 14:57                                       ` Daniel Phillips
2002-02-19 11:39                               ` Daniel Phillips
2002-02-19 12:22                                 ` Hugh Dickins
2002-02-19 12:43                                   ` Daniel Phillips
2002-02-19 10:02                             ` Roman Zippel
2002-02-22  5:29                         ` Daniel Phillips
2002-02-22  6:32                           ` Daniel Phillips
2002-02-22  9:21                             ` [RFC] Page table sharing, leak gone Daniel Phillips
2002-02-19  1:57                     ` [RFC] Page table sharing Daniel Phillips
2002-02-19  1:23                 ` Daniel Phillips
2002-02-19  1:50                 ` Daniel Phillips
2002-02-19  1:53                   ` Linus Torvalds
2002-02-19  2:12                     ` Daniel Phillips
2002-02-18 23:48             ` Daniel Phillips
2002-02-18 23:59             ` Daniel Phillips
2002-02-19  0:03               ` Hugh Dickins
2002-02-19  0:27                 ` Daniel Phillips
2002-02-19  4:27                   ` Eric W. Biederman
2002-02-19 17:30                     ` Linus Torvalds
2002-02-19 18:18 Qing Huang

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=E16dXRt-0001Lo-00@starship.berlin \
    --to=phillips@bonn-fries.net \
    --cc=akpm@zip.com.au \
    --cc=dmccr@us.ibm.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=manfred@colorfullife.com \
    --cc=mingo@redhat.com \
    --cc=riel@conectiva.com.br \
    --cc=rml@tech9.net \
    --cc=torvalds@transmeta.com \
    --cc=wli@holomorphy.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