On 05/03/2015 10:55 PM, Juergen Gross wrote:
> I did a small measurement of the pure locking functions on bare metal
> without and with my patches.
>
> spin_lock() for the first time (lock and code not in cache) dropped from
> about 600 to 500 cycles.
>
> spin_unlock() for first time dropped from 1
On 04/30/2015 03:53 AM, Juergen Gross wrote:
> Paravirtualized spinlocks produce some overhead even if the kernel is
> running on bare metal. The main reason are the more complex locking
> and unlocking functions. Especially unlocking is no longer just one
> instruction but so complex that it is no
On 02/11/2015 09:24 AM, Oleg Nesterov wrote:
> I agree, and I have to admit I am not sure I fully understand why
> unlock uses the locked add. Except we need a barrier to avoid the race
> with the enter_slowpath() users, of course. Perhaps this is the only
> reason?
Right now it needs to be a loc
On 02/10/2015 05:26 AM, Oleg Nesterov wrote:
> On 02/10, Raghavendra K T wrote:
>> On 02/10/2015 06:23 AM, Linus Torvalds wrote:
>>
>>> add_smp(&lock->tickets.head, TICKET_LOCK_INC);
>>> if (READ_ONCE(lock->tickets.tail) & TICKET_SLOWPATH_FLAG) ..
>>>
>>> into something like
>>>
On 02/06/2015 06:49 AM, Raghavendra K T wrote:
> Paravirt spinlock clears slowpath flag after doing unlock.
> As explained by Linus currently it does:
> prev = *lock;
> add_smp(&lock->tickets.head, TICKET_LOCK_INC);
>
> /* add_smp() is a full mb() */
On 08/05/2013 11:05 AM, Konrad Rzeszutek Wilk wrote:
> Jeremy has been a key person in making Linux work with Xen.
> He has been enjoying the last year working on something
> different so reflect that in the maintainers file.
Ack.
J
>
> CC: Jeremy Fitzhardinge
> Sig
On 08/13/2013 01:02 PM, Raghavendra K T wrote:
> * Ingo Molnar [2013-08-13 18:55:52]:
>
>> Would be nice to have a delta fix patch against tip:x86/spinlocks, which
>> I'll then backmerge into that series via rebasing it.
>>
> There was a namespace collision of PER_CPU lock_waiting variable when
>
Commit-ID: 545ac13892ab391049a92108cf59a0d05de7e28c
Gitweb: http://git.kernel.org/tip/545ac13892ab391049a92108cf59a0d05de7e28c
Author: Jeremy Fitzhardinge
AuthorDate: Fri, 9 Aug 2013 19:51:49 +0530
Committer: H. Peter Anvin
CommitDate: Fri, 9 Aug 2013 07:53:05 -0700
x86, spinlock
Commit-ID: 4a1ed4ca681e7df38ed1b609a11aab38cbc515b3
Gitweb: http://git.kernel.org/tip/4a1ed4ca681e7df38ed1b609a11aab38cbc515b3
Author: Jeremy Fitzhardinge
AuthorDate: Fri, 9 Aug 2013 19:51:56 +0530
Committer: H. Peter Anvin
CommitDate: Fri, 9 Aug 2013 07:53:50 -0700
x86, pvticketlock
Commit-ID: bf7aab3ad4b4364a293421d628a912a2153ee1ee
Gitweb: http://git.kernel.org/tip/bf7aab3ad4b4364a293421d628a912a2153ee1ee
Author: Jeremy Fitzhardinge
AuthorDate: Fri, 9 Aug 2013 19:51:52 +0530
Committer: H. Peter Anvin
CommitDate: Fri, 9 Aug 2013 07:53:18 -0700
xen: Defer
Commit-ID: 1ed7bf5f5227169b661c619636f754b98001ec30
Gitweb: http://git.kernel.org/tip/1ed7bf5f5227169b661c619636f754b98001ec30
Author: Jeremy Fitzhardinge
AuthorDate: Fri, 9 Aug 2013 19:51:59 +0530
Committer: H. Peter Anvin
CommitDate: Fri, 9 Aug 2013 07:54:03 -0700
xen, pvticketlock
Commit-ID: b8fa70b51aa76737bdb6b493901ef7376977489c
Gitweb: http://git.kernel.org/tip/b8fa70b51aa76737bdb6b493901ef7376977489c
Author: Jeremy Fitzhardinge
AuthorDate: Fri, 9 Aug 2013 19:51:54 +0530
Committer: H. Peter Anvin
CommitDate: Fri, 9 Aug 2013 07:53:37 -0700
xen, pvticketlocks
Commit-ID: 354714dd2607778692db53947ab93b74956494e5
Gitweb: http://git.kernel.org/tip/354714dd2607778692db53947ab93b74956494e5
Author: Jeremy Fitzhardinge
AuthorDate: Fri, 9 Aug 2013 19:51:55 +0530
Committer: H. Peter Anvin
CommitDate: Fri, 9 Aug 2013 07:53:44 -0700
x86, pvticketlock
Commit-ID: 80bd58fef495d000a02fc5b55ca76d423400e748
Gitweb: http://git.kernel.org/tip/80bd58fef495d000a02fc5b55ca76d423400e748
Author: Jeremy Fitzhardinge
AuthorDate: Fri, 9 Aug 2013 19:51:53 +0530
Committer: H. Peter Anvin
CommitDate: Fri, 9 Aug 2013 07:53:23 -0700
xen, pvticketlock
Commit-ID: 96f853eaa889c7a22718d275b0df7bebdbd6780e
Gitweb: http://git.kernel.org/tip/96f853eaa889c7a22718d275b0df7bebdbd6780e
Author: Jeremy Fitzhardinge
AuthorDate: Fri, 9 Aug 2013 19:51:58 +0530
Committer: H. Peter Anvin
CommitDate: Fri, 9 Aug 2013 07:54:00 -0700
x86, ticketlock
Commit-ID: b798df09f919c52823110a74bd568c6a4e98e6b2
Gitweb: http://git.kernel.org/tip/b798df09f919c52823110a74bd568c6a4e98e6b2
Author: Jeremy Fitzhardinge
AuthorDate: Fri, 9 Aug 2013 19:51:51 +0530
Committer: H. Peter Anvin
CommitDate: Fri, 9 Aug 2013 07:53:14 -0700
x86, ticketlock
Commit-ID: 38eddb85894561ab32c1de4171e1c1582f0efa78
Gitweb: http://git.kernel.org/tip/38eddb85894561ab32c1de4171e1c1582f0efa78
Author: Jeremy Fitzhardinge
AuthorDate: Tue, 6 Aug 2013 17:14:12 +0530
Committer: H. Peter Anvin
CommitDate: Thu, 8 Aug 2013 16:07:01 -0700
xen, pvticketlock
Commit-ID: faf5f87c305fc58464bf8c47d0a5d148ceee2e32
Gitweb: http://git.kernel.org/tip/faf5f87c305fc58464bf8c47d0a5d148ceee2e32
Author: Jeremy Fitzhardinge
AuthorDate: Tue, 6 Aug 2013 17:13:52 +0530
Committer: H. Peter Anvin
CommitDate: Thu, 8 Aug 2013 16:06:58 -0700
x86, ticketlock
Commit-ID: 00de643f44ed84156e18f8b9afa8613d3b37a298
Gitweb: http://git.kernel.org/tip/00de643f44ed84156e18f8b9afa8613d3b37a298
Author: Jeremy Fitzhardinge
AuthorDate: Tue, 6 Aug 2013 17:13:13 +0530
Committer: H. Peter Anvin
CommitDate: Thu, 8 Aug 2013 16:06:50 -0700
x86, pvticketlock
Commit-ID: 26dca1a3262c451846537d8c1f3f56290718b7d4
Gitweb: http://git.kernel.org/tip/26dca1a3262c451846537d8c1f3f56290718b7d4
Author: Jeremy Fitzhardinge
AuthorDate: Tue, 6 Aug 2013 17:11:45 +0530
Committer: H. Peter Anvin
CommitDate: Thu, 8 Aug 2013 16:06:34 -0700
xen: Defer
Commit-ID: c1230bf0bf6c93ff2db93ba0b66839068f498e8b
Gitweb: http://git.kernel.org/tip/c1230bf0bf6c93ff2db93ba0b66839068f498e8b
Author: Jeremy Fitzhardinge
AuthorDate: Tue, 6 Aug 2013 17:11:20 +0530
Committer: H. Peter Anvin
CommitDate: Thu, 8 Aug 2013 16:06:30 -0700
x86, ticketlock
Commit-ID: 9f091fd2047dc4f9cc512e88f818786274fa646f
Gitweb: http://git.kernel.org/tip/9f091fd2047dc4f9cc512e88f818786274fa646f
Author: Jeremy Fitzhardinge
AuthorDate: Tue, 6 Aug 2013 17:12:24 +0530
Committer: H. Peter Anvin
CommitDate: Thu, 8 Aug 2013 16:06:42 -0700
xen, pvticketlocks
Commit-ID: 80aefe73ea1611bb064f4dcfe49b1aa9648922b3
Gitweb: http://git.kernel.org/tip/80aefe73ea1611bb064f4dcfe49b1aa9648922b3
Author: Jeremy Fitzhardinge
AuthorDate: Tue, 6 Aug 2013 17:12:44 +0530
Committer: H. Peter Anvin
CommitDate: Thu, 8 Aug 2013 16:06:46 -0700
x86, pvticketlock
Commit-ID: 82a5c77805c1824da74912f986f6dab241589ac7
Gitweb: http://git.kernel.org/tip/82a5c77805c1824da74912f986f6dab241589ac7
Author: Jeremy Fitzhardinge
AuthorDate: Tue, 6 Aug 2013 17:12:04 +0530
Committer: H. Peter Anvin
CommitDate: Thu, 8 Aug 2013 16:06:38 -0700
xen, pvticketlock
Commit-ID: ee120b6a347e3ce6526bd2380fdf5858d5a8550d
Gitweb: http://git.kernel.org/tip/ee120b6a347e3ce6526bd2380fdf5858d5a8550d
Author: Jeremy Fitzhardinge
AuthorDate: Tue, 6 Aug 2013 17:10:40 +0530
Committer: H. Peter Anvin
CommitDate: Thu, 8 Aug 2013 16:06:23 -0700
x86, spinlock
On 07/30/2013 12:53 PM, Konrad Rzeszutek Wilk wrote:
> Hey,
>
> I was wondering if it would be possible to remove from linux-next
> the three xen trees and instead use a combined tree, similar to the
> x86 tip (so the various maintainers share it)?
>
> The ones that would be removed are:
>
> xen
On 07/14/2013 12:30 PM, Tim Northover wrote:
>> And that is why I think you should just consider "bt $x,y" to be
>> trivially the same thing and not at all ambiguous. Because there is
>> ABSOLUTELY ZERO ambiguity when people write
>>
>>bt $63, mem
>>
>> Zero. Nada. None. The semantics are *exac
reasonable for all other operations because it makes a real
semantic difference, but overly strict for bit operations.
J
> [1]: http://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf
>
> Cc: Jeremy Fitzhardinge
> Cc: Andi Kleen
> Cc: Linus Torvalds
> Cc: Ingo Molnar
>
(Resent without HTML)
On 07/14/2013 10:19 AM, Linus Torvalds wrote:
> Now, there are possible cases where you want to make the size explicit
> because you are mixing memory operand sizes and there can be nasty
> performance implications of doing a 32-bit write and then doing a
> 64-bit read of the
On 06/01/2013 12:21 PM, Raghavendra K T wrote:
> x86/spinlock: Replace pv spinlocks with pv ticketlocks
>
> From: Jeremy Fitzhardinge
I'm not sure what the etiquette is here; I did the work while at Citrix,
but jer...@goop.org is my canonical email address. The Citrix address
is de
On 06/01/2013 01:14 PM, Andi Kleen wrote:
> FWIW I use the paravirt spinlock ops for adding lock elision
> to the spinlocks.
Does lock elision still use the ticketlock algorithm/structure, or are
they different? If they're still basically ticketlocks, then it seems
to me that they're complimentar
On 10/09/2012 06:14 PM, Andrew Morton wrote:
> On Wed, 10 Oct 2012 00:09:12 + KY Srinivasan wrote:
>
+ if (!pg) {
+ *alloc_error = true;
+ return i * alloc_unit;
+ }
+
+ totalram_pages -= alloc_unit;
>>>
On 08/18/2012 07:56 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> The paravirt thunks use a hack of using a static reference to a static
> function to reference that function from the top level statement.
>
> This assumes that gcc always generates static function names in a specific
> format, which
On 08/18/2012 07:56 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> The paravirt patching code assumes that it can reference a
> local assembler label between two different top level assembler
> statements. This does not work with some experimental gcc builds,
> where the assembler code may end up in
On 08/13/2012 03:47 AM, Mel Gorman wrote:
> Resending to correct Jeremy's address.
>
> On Wed, Aug 08, 2012 at 03:50:46PM -0700, David Miller wrote:
>> From: Mel Gorman
>> Date: Tue, 7 Aug 2012 09:55:55 +0100
>>
>>> Commit [c48a11c7: netvm: propagate page->pfmemalloc to skb] is responsible
>>> for
On 07/24/2012 06:15 AM, Yuanhan Liu wrote:
> The old code would call __get_free_page() even though previous
> allocation fail met. This is not needed.
Yeah, I guess, but its hardly worth changing.
J
>
> Signed-off-by: Yuanhan Liu
> Cc: Jeremy Fitzhardinge
> Cc: Tho
Mark McLoughlin wrote:
@@ -371,6 +372,9 @@ void __init dmi_scan_machine(void)
}
}
else {
+ if (e820_all_mapped(0xF, 0xF+0x1, E820_RAM))
+ goto out;
One issue with using the e820 map for this is that a X
Ingo Molnar wrote:
Jeremy, you might want to start tracking x86.git#testing:
http://people.redhat.com/mingo/x86.git/README
if you want to follow the latest & greatest x86.git code.
Right, will do.
J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
Ingo Molnar wrote:
* Vegard Nossum <[EMAIL PROTECTED]> wrote:
asm-x86/kmemcheck.h does seem to be completely missing. Looks like
8db0acefb3025795abe3f37669354677a03de680 "x86: add hooks for
kmemcheck" should have added the file.
Hm. This is x86#testing, no? I don't think there's
CC arch/x86/kernel/traps_32.o
/home/jeremy/hg/xen/paravirt/linux/arch/x86/kernel/traps_32.c:59:27: error:
asm/kmemcheck.h: No such file or directory
asm-x86/kmemcheck.h does seem to be completely missing. Looks like
8db0acefb3025795abe3f37669354677a03de680 "x86: add hooks for kmemcheck"
Markus Armbruster wrote:
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
Markus Armbruster wrote:
This is a pair of Xen para-virtual frontend device drivers:
drivers/video/xen-fbfront.c provides a framebuffer, and
drivers/input/xen-kbdfront provides keyboard and
Arnd Hannemann wrote:
Jeremy Fitzhardinge wrote:
Arnd Hannemann wrote:
This is with 2.6.24.2, but latest-git looks the same:
I also tried with 2.6.23 which crashes instantly, without any output
of the guest.
I'm not too surprised. Non-PAE Xen is a bit of a rarity, a
Linus Torvalds wrote:
This isn't a problem with things like "Signed-off-by:" etc tags, because
they have no automated meaning and don't really change the commit itself,
but the "From:"/"Date:"/"Subject:" markers at the head of the message
really do have real meaning, and get removed from the co
Arnd Hannemann wrote:
This is with 2.6.24.2, but latest-git looks the same:
I also tried with 2.6.23 which crashes instantly, without any output of the
guest.
I'm not too surprised. Non-PAE Xen is a bit of a rarity, and it only
gets tested rarely. Chris Wright did spend some time on it a
Arnd Hannemann wrote:
As paravirtualized xen guests won't work with !X86_PAE, change the Kconfig
accordingly.
!PAE is supposed to work, but it is a rarely used configuration. How
does it fail?
J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
It seems to me that those pages are being handed out as heap pages by
the early allocator. In the Xen case this is OK because there's
nothing magic about them. But if real hardware doesn't reserve these
pages in the E820 map,
Linus Torvalds wrote:
On Thu, 21 Feb 2008, Jeremy Fitzhardinge wrote:
OK. Have you fixed it, or shall I resend?
I'll fix it, but I want people to know so that I don't have to fix things
like this in the future (*).
Linus
(*) I keed, I keed.
H. Peter Anvin wrote:
Still curious about why a pagetable page is ending up in that range
though. Seems like it shouldn't be possible, since we shouldn't be
allowed to allocate from those pages, at least until the DMI probe
has happened... Unless the early allocator is only excluded from
e82
Ian Campbell wrote:
I'll see if I can track down where the page is getting used and have a
go at getting in there first. It must be pretty early to be allocated
already when dmi_scan_machine gets called.
It's possible that the domain builder might have already allocated a PT
at this address. I h
Linus Torvalds wrote:
On Thu, 21 Feb 2008, Jeremy Fitzhardinge wrote:
Signed-off-by: Ian Campbell <[EMAIL PROTECTED]>
From: Ian Campbell <[EMAIL PROTECTED]>
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
This is just wrong. The From: goes at the *top*, and
around the place.
Signed-off-by: Ian Campbell <[EMAIL PROTECTED]>
From: Ian Campbell <[EMAIL PROTECTED]>
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
drivers/block/xen-blkfront.c | 18 ++
1 file chan
Markus Armbruster wrote:
This is a pair of Xen para-virtual frontend device drivers:
drivers/video/xen-fbfront.c provides a framebuffer, and
drivers/input/xen-kbdfront provides keyboard and mouse.
Unless they're actually inter-dependent, could you post this as two
separate patches? I don't
Markus Armbruster wrote:
Forgot to mention: This patch depends on
Subject: [PATCH] xen: Make xen-blkfront write its protocol ABI to xenstore
From: Markus Armbruster <>
Date: Thu, 06 Dec 2007 14:45:53 +0100
http://lkml.org/lkml/2007/12/6/132
Sorry!
Sorry, I haven't pushed this ups
[EMAIL PROTECTED] wrote:
Yep. We removed the guest handle stuff for the initial upstreaming,
since it isn't necessary on x86 and it quietened some of the reviewer
noise. But I expected we'd need to reintroduce it at some stage.
J
--
To unsubscribe from this list: send the line "unsubscri
[EMAIL PROTECTED] wrote:
diff --git a/arch/x86/xen/events.c b/drivers/xen/events.c
similarity index 95%
rename from arch/x86/xen/events.c
rename to drivers/xen/events.c
index dcf613e..7474739 100644
--- a/arch/x86/xen/events.c
+++ b/drivers/xen/events.c
@@ -37,7 +37,9 @@
#include
#include
-
[EMAIL PROTECTED] wrote:
Hi. Recently the xen-ia64 community started to make efforts to merge
xen/ia64 Linux to upstream. The first step is to merge up domU portion.
This patchset is preliminary for xen/ia64 domU linux making the current
xen/x86 domU code more arch generic and adding missing def
Ian Campbell wrote:
On Tue, 2008-02-19 at 23:43 -0800, H. Peter Anvin wrote:
Ian Campbell wrote:
On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
On Sun, Feb 17, 2008 at 06:49:21PM +, Ian Campbell wrote:
x86/xen: Do not scan for DMI unless the DMI region is re
Joel Becker wrote:
Unfortunately that doesn't narrow down what the kernel was actually
trying to do at the time. Clearly a set_pte; looks like someone is
trying to create a writable mapping of an existing pte page.
Does "console=hvc0 earlyprintk=xen" on the kernel command line give any
Joel Becker wrote:
On Sat, Feb 16, 2008 at 01:44:26PM +1100, Jeremy Fitzhardinge wrote:
Joel Becker wrote:
(XEN) mm.c:1825:d109 Bad type (saw 2801 != exp
e000) for mfn 3a2f0f (pfn f0)
(XEN) mm.c:649:d109 Error getting mfn 3a2f0f (pfn f0) from L1 entry
Joel Becker wrote:
On Thu, Feb 14, 2008 at 06:50:52PM +1100, Jeremy Fitzhardinge wrote:
I'm seeing the same problem, with no messages at all from xen
other than "domain crashed, restart disabled" in xend.log. I got a
different comm
H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
Do you also have a patch to update the boot protocol?
Looking for anything different than the root of this thread?
Yes, the patch for the Xen domain builder to boot a bzImage using the
Linux boot protocol rather than the Xen one. Ian&#
Ian Campbell wrote:
On Thu, 2008-02-14 at 17:01 +, Ian Campbell wrote:
I have a xen domain builder patch as well. I was waiting for the Linux
side to gain some traction before putting it forward (I'd attach it
now but it's at home on a laptop which is sleeping).
Here it is:
# HG c
Joel Becker wrote:
On Wed, Feb 13, 2008 at 10:59:33PM +1100, Jeremy Fitzhardinge wrote:
I thought I'd try out 2.6.25-rc1 as a xen 32-bit pae domU the other day.
Unfortunately, I didn't get very far very fast, as the domain just crashed
immediately upon booting, without any direct f
dir
At the early stages of boot, before the kernel pagetable has been
fully initialized, a Xen kernel will still be running off the
Xen-provided pagetables rather than swapper_pg_dir[]. Therefore,
readback cr3 to determine the base of the pagetable rather than
assuming swapper_pg_dir[].
Si
Ingo Molnar wrote:
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
Ingo Molnar wrote:
oops, i thought i pasted that. It was this:
arch/x86/mm/pgtable.c: In function 'pgd_alloc':
arch/x86/mm/pgtable.c:213: error: implicit declaration of function
'quickli
Ingo Molnar wrote:
oops, i thought i pasted that. It was this:
arch/x86/mm/pgtable.c: In function 'pgd_alloc':
arch/x86/mm/pgtable.c:213: error: implicit declaration of function
'quicklist_alloc'
arch/x86/mm/pgtable.c:213: warning: initialization makes pointer from integer
without a cast
arch/
Ingo Molnar wrote:
yes but the early hang is very real so either my hardware is stubbornly
ignoring that your patch is pure code movement (in which case i'll have
to have a word or two with my hardware), or your patch is perhaps wrong
somewhere ;-)
I see what it is. set_pud on 32-bit need
Ingo Molnar wrote:
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
Add a common arch/x86/mm/pgtable.c file for common pagetable functions.
randconfig testing found a build breakage on 32-bit, and that got
bisected down to this patch of yours.
Couldn't reproduce. W
Ingo Molnar wrote:
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
Common definitions for 4-level pagetable functions.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/mm/pgtable.c|7 ++
include/asm-x86/pgalloc
Ingo Molnar wrote:
another thing: these inlines are a bit fat and they are used in more
than one place. Please move them into pgtable.c. The rule of thumb is:
if an inline is more than 2 lines big, it is a likely candidate for
uninlining. (and even many 2-liners, and even some 1-liners are
can
Common definitions for 3-level pagetable functions.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/mm/pgtable.c|8
arch/x86/mm/pgtable_32.c | 10 --
include/asm-x86/pgalloc.h| 31 +++
include/a
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/mm/pgtable.c | 24 +---
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -39,32
Common definitions for 4-level pagetable functions.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/mm/pgtable.c|7 ++
include/asm-x86/pgalloc.h| 46 --
include/asm-x86/pgalloc_32.h
Add a common arch/x86/mm/pgtable.c file for common pagetable functions.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/mm/Makefile_32 |2
arch/x86/mm/Makefile_64 |2
arch/x86/mm/pgtable.c| 234 ++
arch/
Common definitions for 2-level pagetable functions.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/mm/pgtable.c|6 ++
arch/x86/mm/pgtable_32.c |6 --
include/asm-x86/pgalloc.h| 16
include/asm-x86/pgalloc_32.h
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/mm/pageattr.c |2 --
include/asm-x86/pgalloc.h| 11 +++
include/asm-x86/pgalloc_32.h | 10 --
3 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/arch/x86/mm/pageattr.c b/arch/
Hi Ingo,
This series does more unification of pgalloc, and creates a unified
mm/pgtable.c for common pagetable functions. Ends up removing
pgalloc_32/64.h in favour of pgalloc.h.
[ I thought I'd mailed this earlier, but I don't see it on lkml.
Maybe I created the mbox without sending it. Anyway
Convert asm-x86/pgalloc_64.h from macros into inline functions.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-x86/pgalloc_64.h | 41 ++---
1 file changed, 30 insertions(+), 11 deletions(-)
diff --git a/arch/x86/mm/init_64.c
Rename (alloc|release)_(pt|pd) to pte/pmd to explicitly match the name
of the appropriate pagetable level structure.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/kernel/paravirt.c | 10 +-
arch/x86/kernel/vmi_32.c | 20 ++--
arch/
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-x86/pgtable.h | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/include/asm-x86/pgtable.h b/include/asm-x86/pgtable.h
--- a/include/asm-x86/pgtable.h
+++ b/include/asm-x86/pgt
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-x86/pgtable.h | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/include/asm-x86/pgtable.h b/include/asm-x86/pgtable.h
--- a/include/asm-x86/pgtable.h
+++ b/include/asm-x86/pgt
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/kernel/paravirt.c |2 ++
arch/x86/mm/pgtable.c |1 +
include/asm-x86/paravirt.h | 11 +++
include/asm-x86/pgalloc.h |3 +++
4 files changed, 17 insertions(+)
diff --git a/arch/x86/kernel/paravi
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-x86/pgtable.h | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/include/asm-x86/pgtable.h b/include/asm-x86/pgtable.h
--- a/include/asm-x86/pgtable.h
+++ b/include/a
Hi Ingo,
This series:
1. Renames the alloc/release_{pt,pd} calls to _pte, _pmd so that its
clear what they operate on.
2. Adds alloc/release_pud, and puts calls in the appropriate places
3. Demacros some stuff in pgtable.h
A bit eclectic, but all fairly straightforward (and no changes to
n
Andi Kleen wrote:
Why? 64-bit Xen will need this to be set_pmd if its an update to L2 of
the table.
Then change_page_attr() and hugepages will already not work because they both
do exactly that.
And I didn't want to duplicate this manual code for the GBpages case, so i
changed it ever
Andi Kleen wrote:
[Actually not needed for gbpages, but an indepedent, but related cleanup]
Use set_pte() for setting up the 2MB pages in the direct mapping similar
to what the earlier GBPAGES patches did for the 1GB PUDs.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86/mm/init_6
Revert "defer cr3 reload when doing pud_clear()" since I'm going to
replace it.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/mm/pgtable_32.c |7 ---
include/asm-x86/pgtable-3level.h | 21 ++---
2 files changed
The constructors for PAE and non-PAE pgd_ctors are more or less
identical, and can be made into the same function.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: William Irwin <[EMAIL PROTECTED]>
---
arch/x86/mm/pgtable_32.c | 58 +
only
other use of pud_clear is during a large (1Gbyte+) munmap, and those
are sufficiently rare that a couple of cr3 reloads won't hurt.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-x86/pgtable-3level.h | 11 +++
1 file changed, 7 insertions(+), 4 de
Remove bogus reference to "Pentium-II erratum A13" and point to the
actual canonical source of information about what requirements x86
processors have for PAE pagetable updates.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-x86/pgalloc_32.h |6 +++
Hi Ingo,
Here's a followup set from that last batch of patches:
1. fix up the pgd_ctor merge, so that non-PAE will end up getting
kernel mappings
2. revert "optimise-pud_clear-cr3-reload"
3. only do a cr3 reload if pud_clear is being used on the active pagetable
4. update documentation abo
Ingo Molnar wrote:
FYI, only this one applied to the latest x86.git tree, could you please
resend? I guess the pgalloc.h related revert interfered.
OK. I'll do a quick rebase to this morning's tree and resend.
J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Ingo Molnar wrote:
thanks, applied. I'm wondering, where did we break that?
In the "PAE from boot" patch, I would guess.
J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.o
Xen currently needs swapper_pg_dir page aligned and sized. This fixes
the second part of that...
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/kernel/head_32.S |1 +
1 file changed, 1 ins
Ingo Molnar wrote:
* Ian Campbell <[EMAIL PROTECTED]> wrote:
Some important parts of f6df72e71eba621b2f5c49b3a763116fac748f6e got
dropped along the way, reintroduce them.
thanks, applied. AFAICS it should only affect paravirt, not the native
kernel, right?
Correct.
J
--
To u
From: Ian Campbell <[EMAIL PROTECTED]>
Date: Thu, 31 Jan 2008 18:56:06 +
Subject: [PATCH] x86: fix early_ioremap pagetable ops for paravirt.
Some important parts of f6df72e71eba621b2f5c49b3a763116fac748f6e got dropped
along the way, reintroduce them.
Yep.
Acked-by: Jeremy Fitzh
Ingo Molnar wrote:
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
But I guess I overlooked the comment...
I guess the fix is to scatter linux/pagemap.h into the appropriate
places where these macros are used (asm-generic/tlb.h, for a start).
no. The fix is always to un
Something in current x86.git is making my kernel build as ia64. I don't
see any obvious change which might be the cause.
: ezr:pts/6; make oldconfig
make -C /home/jeremy/hg/xen/paravirt/linux
O=/home/jeremy/hg/xen/paravirt/linux-i386/. oldconfig
/home/jeremy/hg/xen/paravirt/linux/arch/ia64/scr
Ingo Molnar wrote:
* Adrian Bunk <[EMAIL PROTECTED]> wrote:
What about the breakages caused by commit
a5a19c63f4e55e32dc0bc3d936d7f94793d8b380 (this commit broke the
defconfig compilation on at least avr32, blackfin, sh, sparc and uml)?
the patch below fixes that.
Is it sa
Adrian Bunk wrote:
On Thu, Jan 31, 2008 at 05:15:23PM +0100, Ingo Molnar wrote:
* Adrian Bunk <[EMAIL PROTECTED]> wrote:
On Thu, Jan 31, 2008 at 05:00:33PM +0100, Ingo Molnar wrote:
* Adrian Bunk <[EMAIL PROTECTED]> wrote:
You tested x86 but broke more than half a doz
1 - 100 of 1859 matches
Mail list logo
