* [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd()
@ 2003-10-24 20:56 Luck, Tony
2003-10-24 22:01 ` David Mosberger
` (8 more replies)
0 siblings, 9 replies; 20+ messages in thread
From: Luck, Tony @ 2003-10-24 20:56 UTC (permalink / raw)
To: linux-ia64
This patch was accepted into 2.5.55, attributed to "davej@uk".
This code will prefetch from beyond the end of the page table
being cleared ... which is clearly a bad thing if the page table
in question is allocated from the last page of memory (or precedes
a hole on a discontig mem system).
-Tony Luck
diff -ru linux-2.4.23-pre8/mm/memory.c fix/mm/memory.c
--- linux-2.4.23-pre8/mm/memory.c Fri Oct 24 13:37:23 2003
+++ fix/mm/memory.c Fri Oct 24 13:40:47 2003
@@ -120,10 +120,8 @@
}
pmd = pmd_offset(dir, 0);
pgd_clear(dir);
- for (j = 0; j < PTRS_PER_PMD ; j++) {
- prefetchw(pmd+j+(PREFETCH_STRIDE/16));
+ for (j = 0; j < PTRS_PER_PMD ; j++)
free_one_pmd(pmd+j);
- }
pmd_free(pmd);
}
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd()
2003-10-24 20:56 [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd() Luck, Tony
@ 2003-10-24 22:01 ` David Mosberger
2003-10-24 22:16 ` Luck, Tony
` (7 subsequent siblings)
8 siblings, 0 replies; 20+ messages in thread
From: David Mosberger @ 2003-10-24 22:01 UTC (permalink / raw)
To: linux-ia64
>>>>> On Fri, 24 Oct 2003 13:56:31 -0700, "Luck, Tony" <tony.luck@intel.com> said:
Tony> This patch was accepted into 2.5.55, attributed to "davej@uk".
Tony> This code will prefetch from beyond the end of the page table
Tony> being cleared ... which is clearly a bad thing if the page
Tony> table in question is allocated from the last page of memory
Tony> (or precedes a hole on a discontig mem system).
Different arches behave differently, though. In the case of ia64,
it'a always safe to prefetch (even with lfetch.fault).
--david
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd()
2003-10-24 20:56 [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd() Luck, Tony
2003-10-24 22:01 ` David Mosberger
@ 2003-10-24 22:16 ` Luck, Tony
2003-10-24 22:21 ` David Mosberger
` (6 subsequent siblings)
8 siblings, 0 replies; 20+ messages in thread
From: Luck, Tony @ 2003-10-24 22:16 UTC (permalink / raw)
To: linux-ia64
> Tony> This patch was accepted into 2.5.55, attributed to "davej@uk".
> Tony> This code will prefetch from beyond the end of the page table
> Tony> being cleared ... which is clearly a bad thing if the page
> Tony> table in question is allocated from the last page of memory
> Tony> (or precedes a hole on a discontig mem system).
>
> Different arches behave differently, though. In the case of ia64,
> it'a always safe to prefetch (even with lfetch.fault).
Not quite always ... this was how I found the efi trim.bottom bug, since
Linux had allocated a pgd at 0xa00000-16k, and the lfetch that reached
out beyond the end of the page to the uncacheable address 0xa00000 took
an MCA.
A pgd in the last page of a granule that is followed by an uncacheable
address would do the same with lfetch.fault, wouldn't it?
-Tony
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd()
2003-10-24 20:56 [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd() Luck, Tony
2003-10-24 22:01 ` David Mosberger
2003-10-24 22:16 ` Luck, Tony
@ 2003-10-24 22:21 ` David Mosberger
2003-10-25 20:10 ` Pavel Machek
` (5 subsequent siblings)
8 siblings, 0 replies; 20+ messages in thread
From: David Mosberger @ 2003-10-24 22:21 UTC (permalink / raw)
To: linux-ia64
>>>>> On Fri, 24 Oct 2003 15:16:59 -0700, "Luck, Tony" <tony.luck@intel.com> said:
Tony> This patch was accepted into 2.5.55, attributed to "davej@uk".
Tony> This code will prefetch from beyond the end of the page table
Tony> being cleared ... which is clearly a bad thing if the page
Tony> table in question is allocated from the last page of memory
Tony> (or precedes a hole on a discontig mem system).
>> Different arches behave differently, though. In the case of ia64,
>> it'a always safe to prefetch (even with lfetch.fault).
Tony> Not quite always ... this was how I found the efi trim.bottom
Tony> bug, since Linux had allocated a pgd at 0xa00000-16k, and the
Tony> lfetch that reached out beyond the end of the page to the
Tony> uncacheable address 0xa00000 took an MCA.
But don't confuse cause and effect! The MCA was caused by a bad TLB
entry. The lfetch only triggered the latent bug (as might have a
instruction-prefetch).
Tony> A pgd in the last page of a granule that is followed by an uncacheable
Tony> address would do the same with lfetch.fault, wouldn't it?
No, lfetch to uncacheable translations have no effect.
--david
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd()
2003-10-24 20:56 [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd() Luck, Tony
` (2 preceding siblings ...)
2003-10-24 22:21 ` David Mosberger
@ 2003-10-25 20:10 ` Pavel Machek
2003-10-26 14:51 ` Dave Jones
` (4 subsequent siblings)
8 siblings, 0 replies; 20+ messages in thread
From: Pavel Machek @ 2003-10-25 20:10 UTC (permalink / raw)
To: linux-ia64
Hi!
> This patch was accepted into 2.5.55, attributed to "davej@uk".
Dave Jones?n
> This code will prefetch from beyond the end of the page table
> being cleared ... which is clearly a bad thing if the page table
> in question is allocated from the last page of memory (or precedes
> a hole on a discontig mem system).
Prefetching random addresses should be safe... Well for 2.4 we
probably want to play it safe and kill it, but I guess quite a few
pieces rely on prefretch(NULL) doing nothing...
> diff -ru linux-2.4.23-pre8/mm/memory.c fix/mm/memory.c
> --- linux-2.4.23-pre8/mm/memory.c Fri Oct 24 13:37:23 2003
> +++ fix/mm/memory.c Fri Oct 24 13:40:47 2003
> @@ -120,10 +120,8 @@
> }
> pmd = pmd_offset(dir, 0);
> pgd_clear(dir);
> - for (j = 0; j < PTRS_PER_PMD ; j++) {
> - prefetchw(pmd+j+(PREFETCH_STRIDE/16));
> + for (j = 0; j < PTRS_PER_PMD ; j++)
> free_one_pmd(pmd+j);
> - }
> pmd_free(pmd);
> }
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd()
2003-10-24 20:56 [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd() Luck, Tony
` (3 preceding siblings ...)
2003-10-25 20:10 ` Pavel Machek
@ 2003-10-26 14:51 ` Dave Jones
2003-10-27 9:52 ` Pavel Machek
` (3 subsequent siblings)
8 siblings, 0 replies; 20+ messages in thread
From: Dave Jones @ 2003-10-26 14:51 UTC (permalink / raw)
To: linux-ia64
On Sat, Oct 25, 2003 at 10:10:10PM +0200, Pavel Machek wrote:
> > This patch was accepted into 2.5.55, attributed to "davej@uk".
> Dave Jones?n
Yep.
> > This code will prefetch from beyond the end of the page table
> > being cleared ... which is clearly a bad thing if the page table
> > in question is allocated from the last page of memory (or precedes
> > a hole on a discontig mem system).
> Prefetching random addresses should be safe...
It isn't on some CPUs. Early athlons go bang when you prefetch
past the end of RAM into unmapped memory for eg.
Dave
--
Dave Jones http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd()
2003-10-24 20:56 [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd() Luck, Tony
` (4 preceding siblings ...)
2003-10-26 14:51 ` Dave Jones
@ 2003-10-27 9:52 ` Pavel Machek
2003-10-27 11:58 ` Dave Jones
` (2 subsequent siblings)
8 siblings, 0 replies; 20+ messages in thread
From: Pavel Machek @ 2003-10-27 9:52 UTC (permalink / raw)
To: linux-ia64
Hi!
> > > This code will prefetch from beyond the end of the page table
> > > being cleared ... which is clearly a bad thing if the page table
> > > in question is allocated from the last page of memory (or precedes
> > > a hole on a discontig mem system).
> > Prefetching random addresses should be safe...
>
> It isn't on some CPUs. Early athlons go bang when you prefetch
> past the end of RAM into unmapped memory for eg.
Well, broken HW :-(, but andi's patch should fix up for that.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd()
2003-10-24 20:56 [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd() Luck, Tony
` (5 preceding siblings ...)
2003-10-27 9:52 ` Pavel Machek
@ 2003-10-27 11:58 ` Dave Jones
2003-10-30 20:57 ` Bjorn Helgaas
2003-10-30 21:36 ` Luck, Tony
8 siblings, 0 replies; 20+ messages in thread
From: Dave Jones @ 2003-10-27 11:58 UTC (permalink / raw)
To: linux-ia64
On Mon, Oct 27, 2003 at 10:52:59AM +0100, Pavel Machek wrote:
> > It isn't on some CPUs. Early athlons go bang when you prefetch
> > past the end of RAM into unmapped memory for eg.
>
> Well, broken HW :-(
There's a lot of it out there. If we didn't try to work around
some of it, we'd end up running on less < 10% of machines out there 8-)
> but andi's patch should fix up for that.
Different bug.
Dave
--
Dave Jones http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd()
2003-10-24 20:56 [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd() Luck, Tony
` (6 preceding siblings ...)
2003-10-27 11:58 ` Dave Jones
@ 2003-10-30 20:57 ` Bjorn Helgaas
2003-10-30 21:36 ` Luck, Tony
8 siblings, 0 replies; 20+ messages in thread
From: Bjorn Helgaas @ 2003-10-30 20:57 UTC (permalink / raw)
To: linux-ia64
On Friday 24 October 2003 4:21 pm, David Mosberger wrote:
> >>>>> On Fri, 24 Oct 2003 15:16:59 -0700, "Luck, Tony" <tony.luck@intel.com> said:
> >> Different arches behave differently, though. In the case of ia64,
> >> it'a always safe to prefetch (even with lfetch.fault).
>
> Tony> Not quite always ... this was how I found the efi trim.bottom
> Tony> bug, since Linux had allocated a pgd at 0xa00000-16k, and the
> Tony> lfetch that reached out beyond the end of the page to the
> Tony> uncacheable address 0xa00000 took an MCA.
>
> But don't confuse cause and effect! The MCA was caused by a bad TLB
> entry. The lfetch only triggered the latent bug (as might have a
> instruction-prefetch).
I'm assuming that the EFI memory map trim fixes prevent the bad
TLB entry, and hence, the prefetching patch is not required by ia64
in 2.4. Tony, let me know if otherwise.
Bjorn
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd()
2003-10-24 20:56 [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd() Luck, Tony
` (7 preceding siblings ...)
2003-10-30 20:57 ` Bjorn Helgaas
@ 2003-10-30 21:36 ` Luck, Tony
8 siblings, 0 replies; 20+ messages in thread
From: Luck, Tony @ 2003-10-30 21:36 UTC (permalink / raw)
To: linux-ia64
> On Friday 24 October 2003 4:21 pm, David Mosberger wrote:
> > >>>>> On Fri, 24 Oct 2003 15:16:59 -0700, "Luck, Tony"
> <tony.luck@intel.com> said:
> > >> Different arches behave differently, though. In the
> case of ia64,
> > >> it'a always safe to prefetch (even with lfetch.fault).
> >
> > Tony> Not quite always ... this was how I found the efi
> trim.bottom
> > Tony> bug, since Linux had allocated a pgd at
> 0xa00000-16k, and the
> > Tony> lfetch that reached out beyond the end of the page to the
> > Tony> uncacheable address 0xa00000 took an MCA.
> >
> > But don't confuse cause and effect! The MCA was caused by a bad TLB
> > entry. The lfetch only triggered the latent bug (as might have a
> > instruction-prefetch).
>
> I'm assuming that the EFI memory map trim fixes prevent the bad
> TLB entry, and hence, the prefetching patch is not required by ia64
> in 2.4. Tony, let me know if otherwise.
If EFI trim is doing its job (and the current version now seems
to be handling all cases correctly), then you should no longer
be able to have a TLB entry erroneously marking an uncacheable
area of memory for cacheable access ... so you can keep the prefetch
for ia64 (David pointed out that dropping this prefetch has a
severe negative impact on lmbench fork+execve test).
-Tony
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd()
@ 2003-10-30 21:36 Luck, Tony
0 siblings, 0 replies; 20+ messages in thread
From: Luck, Tony @ 2003-10-30 21:36 UTC (permalink / raw)
To: Bjorn Helgaas, davidm, David Mosberger
Cc: davidm, linux-ia64, linux-kernel, marcelo
> On Friday 24 October 2003 4:21 pm, David Mosberger wrote:
> > >>>>> On Fri, 24 Oct 2003 15:16:59 -0700, "Luck, Tony"
> <tony.luck@intel.com> said:
> > >> Different arches behave differently, though. In the
> case of ia64,
> > >> it'a always safe to prefetch (even with lfetch.fault).
> >
> > Tony> Not quite always ... this was how I found the efi
> trim.bottom
> > Tony> bug, since Linux had allocated a pgd at
> 0xa00000-16k, and the
> > Tony> lfetch that reached out beyond the end of the page to the
> > Tony> uncacheable address 0xa00000 took an MCA.
> >
> > But don't confuse cause and effect! The MCA was caused by a bad TLB
> > entry. The lfetch only triggered the latent bug (as might have a
> > instruction-prefetch).
>
> I'm assuming that the EFI memory map trim fixes prevent the bad
> TLB entry, and hence, the prefetching patch is not required by ia64
> in 2.4. Tony, let me know if otherwise.
If EFI trim is doing its job (and the current version now seems
to be handling all cases correctly), then you should no longer
be able to have a TLB entry erroneously marking an uncacheable
area of memory for cacheable access ... so you can keep the prefetch
for ia64 (David pointed out that dropping this prefetch has a
severe negative impact on lmbench fork+execve test).
-Tony
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd()
2003-10-24 22:21 ` David Mosberger
@ 2003-10-30 20:57 ` Bjorn Helgaas
0 siblings, 0 replies; 20+ messages in thread
From: Bjorn Helgaas @ 2003-10-30 20:57 UTC (permalink / raw)
To: davidm, David Mosberger, Luck, Tony
Cc: davidm, linux-ia64, linux-kernel, marcelo
On Friday 24 October 2003 4:21 pm, David Mosberger wrote:
> >>>>> On Fri, 24 Oct 2003 15:16:59 -0700, "Luck, Tony" <tony.luck@intel.com> said:
> >> Different arches behave differently, though. In the case of ia64,
> >> it'a always safe to prefetch (even with lfetch.fault).
>
> Tony> Not quite always ... this was how I found the efi trim.bottom
> Tony> bug, since Linux had allocated a pgd at 0xa00000-16k, and the
> Tony> lfetch that reached out beyond the end of the page to the
> Tony> uncacheable address 0xa00000 took an MCA.
>
> But don't confuse cause and effect! The MCA was caused by a bad TLB
> entry. The lfetch only triggered the latent bug (as might have a
> instruction-prefetch).
I'm assuming that the EFI memory map trim fixes prevent the bad
TLB entry, and hence, the prefetching patch is not required by ia64
in 2.4. Tony, let me know if otherwise.
Bjorn
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd()
2003-10-27 9:52 ` Pavel Machek
@ 2003-10-27 11:58 ` Dave Jones
0 siblings, 0 replies; 20+ messages in thread
From: Dave Jones @ 2003-10-27 11:58 UTC (permalink / raw)
To: Pavel Machek; +Cc: Luck, Tony, Bjorn Helgaas, linux-ia64, linux-kernel, marcelo
On Mon, Oct 27, 2003 at 10:52:59AM +0100, Pavel Machek wrote:
> > It isn't on some CPUs. Early athlons go bang when you prefetch
> > past the end of RAM into unmapped memory for eg.
>
> Well, broken HW :-(
There's a lot of it out there. If we didn't try to work around
some of it, we'd end up running on less < 10% of machines out there 8-)
> but andi's patch should fix up for that.
Different bug.
Dave
--
Dave Jones http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd()
2003-10-26 14:51 ` Dave Jones
@ 2003-10-27 9:52 ` Pavel Machek
2003-10-27 11:58 ` Dave Jones
0 siblings, 1 reply; 20+ messages in thread
From: Pavel Machek @ 2003-10-27 9:52 UTC (permalink / raw)
To: Dave Jones, Luck, Tony, Bjorn Helgaas, linux-ia64, linux-kernel, marcelo
Hi!
> > > This code will prefetch from beyond the end of the page table
> > > being cleared ... which is clearly a bad thing if the page table
> > > in question is allocated from the last page of memory (or precedes
> > > a hole on a discontig mem system).
> > Prefetching random addresses should be safe...
>
> It isn't on some CPUs. Early athlons go bang when you prefetch
> past the end of RAM into unmapped memory for eg.
Well, broken HW :-(, but andi's patch should fix up for that.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd()
2003-10-25 20:10 ` Pavel Machek
@ 2003-10-26 14:51 ` Dave Jones
2003-10-27 9:52 ` Pavel Machek
0 siblings, 1 reply; 20+ messages in thread
From: Dave Jones @ 2003-10-26 14:51 UTC (permalink / raw)
To: Pavel Machek; +Cc: Luck, Tony, Bjorn Helgaas, linux-ia64, linux-kernel, marcelo
On Sat, Oct 25, 2003 at 10:10:10PM +0200, Pavel Machek wrote:
> > This patch was accepted into 2.5.55, attributed to "davej@uk".
> Dave Jones?n
Yep.
> > This code will prefetch from beyond the end of the page table
> > being cleared ... which is clearly a bad thing if the page table
> > in question is allocated from the last page of memory (or precedes
> > a hole on a discontig mem system).
> Prefetching random addresses should be safe...
It isn't on some CPUs. Early athlons go bang when you prefetch
past the end of RAM into unmapped memory for eg.
Dave
--
Dave Jones http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd()
2003-10-24 20:56 Luck, Tony
2003-10-24 22:01 ` David Mosberger
@ 2003-10-25 20:10 ` Pavel Machek
2003-10-26 14:51 ` Dave Jones
1 sibling, 1 reply; 20+ messages in thread
From: Pavel Machek @ 2003-10-25 20:10 UTC (permalink / raw)
To: Luck, Tony; +Cc: Bjorn Helgaas, linux-ia64, linux-kernel, marcelo
Hi!
> This patch was accepted into 2.5.55, attributed to "davej@uk".
Dave Jones?n
> This code will prefetch from beyond the end of the page table
> being cleared ... which is clearly a bad thing if the page table
> in question is allocated from the last page of memory (or precedes
> a hole on a discontig mem system).
Prefetching random addresses should be safe... Well for 2.4 we
probably want to play it safe and kill it, but I guess quite a few
pieces rely on prefretch(NULL) doing nothing...
> diff -ru linux-2.4.23-pre8/mm/memory.c fix/mm/memory.c
> --- linux-2.4.23-pre8/mm/memory.c Fri Oct 24 13:37:23 2003
> +++ fix/mm/memory.c Fri Oct 24 13:40:47 2003
> @@ -120,10 +120,8 @@
> }
> pmd = pmd_offset(dir, 0);
> pgd_clear(dir);
> - for (j = 0; j < PTRS_PER_PMD ; j++) {
> - prefetchw(pmd+j+(PREFETCH_STRIDE/16));
> + for (j = 0; j < PTRS_PER_PMD ; j++)
> free_one_pmd(pmd+j);
> - }
> pmd_free(pmd);
> }
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd()
2003-10-24 22:16 Luck, Tony
@ 2003-10-24 22:21 ` David Mosberger
2003-10-30 20:57 ` Bjorn Helgaas
0 siblings, 1 reply; 20+ messages in thread
From: David Mosberger @ 2003-10-24 22:21 UTC (permalink / raw)
To: Luck, Tony; +Cc: davidm, Bjorn Helgaas, linux-ia64, linux-kernel, marcelo
>>>>> On Fri, 24 Oct 2003 15:16:59 -0700, "Luck, Tony" <tony.luck@intel.com> said:
Tony> This patch was accepted into 2.5.55, attributed to "davej@uk".
Tony> This code will prefetch from beyond the end of the page table
Tony> being cleared ... which is clearly a bad thing if the page
Tony> table in question is allocated from the last page of memory
Tony> (or precedes a hole on a discontig mem system).
>> Different arches behave differently, though. In the case of ia64,
>> it'a always safe to prefetch (even with lfetch.fault).
Tony> Not quite always ... this was how I found the efi trim.bottom
Tony> bug, since Linux had allocated a pgd at 0xa00000-16k, and the
Tony> lfetch that reached out beyond the end of the page to the
Tony> uncacheable address 0xa00000 took an MCA.
But don't confuse cause and effect! The MCA was caused by a bad TLB
entry. The lfetch only triggered the latent bug (as might have a
instruction-prefetch).
Tony> A pgd in the last page of a granule that is followed by an uncacheable
Tony> address would do the same with lfetch.fault, wouldn't it?
No, lfetch to uncacheable translations have no effect.
--david
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd()
@ 2003-10-24 22:16 Luck, Tony
2003-10-24 22:21 ` David Mosberger
0 siblings, 1 reply; 20+ messages in thread
From: Luck, Tony @ 2003-10-24 22:16 UTC (permalink / raw)
To: davidm; +Cc: Bjorn Helgaas, linux-ia64, linux-kernel, marcelo
> Tony> This patch was accepted into 2.5.55, attributed to "davej@uk".
> Tony> This code will prefetch from beyond the end of the page table
> Tony> being cleared ... which is clearly a bad thing if the page
> Tony> table in question is allocated from the last page of memory
> Tony> (or precedes a hole on a discontig mem system).
>
> Different arches behave differently, though. In the case of ia64,
> it'a always safe to prefetch (even with lfetch.fault).
Not quite always ... this was how I found the efi trim.bottom bug, since
Linux had allocated a pgd at 0xa00000-16k, and the lfetch that reached
out beyond the end of the page to the uncacheable address 0xa00000 took
an MCA.
A pgd in the last page of a granule that is followed by an uncacheable
address would do the same with lfetch.fault, wouldn't it?
-Tony
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd()
2003-10-24 20:56 Luck, Tony
@ 2003-10-24 22:01 ` David Mosberger
2003-10-25 20:10 ` Pavel Machek
1 sibling, 0 replies; 20+ messages in thread
From: David Mosberger @ 2003-10-24 22:01 UTC (permalink / raw)
To: Luck, Tony; +Cc: Bjorn Helgaas, linux-ia64, linux-kernel, marcelo
>>>>> On Fri, 24 Oct 2003 13:56:31 -0700, "Luck, Tony" <tony.luck@intel.com> said:
Tony> This patch was accepted into 2.5.55, attributed to "davej@uk".
Tony> This code will prefetch from beyond the end of the page table
Tony> being cleared ... which is clearly a bad thing if the page
Tony> table in question is allocated from the last page of memory
Tony> (or precedes a hole on a discontig mem system).
Different arches behave differently, though. In the case of ia64,
it'a always safe to prefetch (even with lfetch.fault).
--david
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd()
@ 2003-10-24 20:56 Luck, Tony
2003-10-24 22:01 ` David Mosberger
2003-10-25 20:10 ` Pavel Machek
0 siblings, 2 replies; 20+ messages in thread
From: Luck, Tony @ 2003-10-24 20:56 UTC (permalink / raw)
To: Bjorn Helgaas, linux-ia64, linux-kernel; +Cc: marcelo
This patch was accepted into 2.5.55, attributed to "davej@uk".
This code will prefetch from beyond the end of the page table
being cleared ... which is clearly a bad thing if the page table
in question is allocated from the last page of memory (or precedes
a hole on a discontig mem system).
-Tony Luck
diff -ru linux-2.4.23-pre8/mm/memory.c fix/mm/memory.c
--- linux-2.4.23-pre8/mm/memory.c Fri Oct 24 13:37:23 2003
+++ fix/mm/memory.c Fri Oct 24 13:40:47 2003
@@ -120,10 +120,8 @@
}
pmd = pmd_offset(dir, 0);
pgd_clear(dir);
- for (j = 0; j < PTRS_PER_PMD ; j++) {
- prefetchw(pmd+j+(PREFETCH_STRIDE/16));
+ for (j = 0; j < PTRS_PER_PMD ; j++)
free_one_pmd(pmd+j);
- }
pmd_free(pmd);
}
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2003-10-30 21:36 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-24 20:56 [PATCH 2.4.23-pre8] Remove broken prefetching in free_one_pgd() Luck, Tony
2003-10-24 22:01 ` David Mosberger
2003-10-24 22:16 ` Luck, Tony
2003-10-24 22:21 ` David Mosberger
2003-10-25 20:10 ` Pavel Machek
2003-10-26 14:51 ` Dave Jones
2003-10-27 9:52 ` Pavel Machek
2003-10-27 11:58 ` Dave Jones
2003-10-30 20:57 ` Bjorn Helgaas
2003-10-30 21:36 ` Luck, Tony
2003-10-24 20:56 Luck, Tony
2003-10-24 22:01 ` David Mosberger
2003-10-25 20:10 ` Pavel Machek
2003-10-26 14:51 ` Dave Jones
2003-10-27 9:52 ` Pavel Machek
2003-10-27 11:58 ` Dave Jones
2003-10-24 22:16 Luck, Tony
2003-10-24 22:21 ` David Mosberger
2003-10-30 20:57 ` Bjorn Helgaas
2003-10-30 21:36 Luck, Tony
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.