Displaying 20 results from an estimated 100 matches similar to: "[PATCH 3/9] 00mm3 lazy mmu mode hooks.patch"
2007 Apr 18
1
[PATCH 2/9] 00mm2 pte clear not present.patch
Change pte_clear_full to a more appropriately named pte_clear_not_present,
allowing optimizations when not-present mapping changes need not be
reflected in the hardware TLB for protected page table modes. There is
also another case that can use it in the fremap code.
Signed-off-by: Zachary Amsden <zach@vmware.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
---
2007 Oct 01
2
[PATCH RFC] paravirt: cleanup lazy mode handling
Currently, the set_lazy_mode pv_op is overloaded with 5 functions:
1. enter lazy cpu mode
2. leave lazy cpu mode
3. enter lazy mmu mode
4. leave lazy mmu mode
5. flush pending batched operations
This complicates each paravirt backend, since it needs to deal with
all the possible state transitions, handling flushing, etc. In
particular, flushing is quite distinct from the other 4 functions,
2007 Oct 01
2
[PATCH RFC] paravirt: cleanup lazy mode handling
Currently, the set_lazy_mode pv_op is overloaded with 5 functions:
1. enter lazy cpu mode
2. leave lazy cpu mode
3. enter lazy mmu mode
4. leave lazy mmu mode
5. flush pending batched operations
This complicates each paravirt backend, since it needs to deal with
all the possible state transitions, handling flushing, etc. In
particular, flushing is quite distinct from the other 4 functions,
2014 Feb 27
3
[PATCH] xen/grant-table: Refactor gnttab_[un]map_refs to avoid m2p_override
(This is a continuation of "[PATCH v9] xen/grant-table: Avoid m2p_override
during mapping")
The grant mapping API does m2p_override unnecessarily: only gntdev needs it,
for blkback and future netback patches it just cause a lock contention, as
those pages never go to userspace. Therefore this series does the following:
- the bulk of the original function (everything after the mapping
2014 Feb 27
3
[PATCH] xen/grant-table: Refactor gnttab_[un]map_refs to avoid m2p_override
(This is a continuation of "[PATCH v9] xen/grant-table: Avoid m2p_override
during mapping")
The grant mapping API does m2p_override unnecessarily: only gntdev needs it,
for blkback and future netback patches it just cause a lock contention, as
those pages never go to userspace. Therefore this series does the following:
- the bulk of the original function (everything after the mapping
2007 Oct 09
0
[PATCH RFC REPOST 2/2] paravirt: clean up lazy mode handling
[ I think this is a straight repost this patch, which addresses all the
previous comments. I'd like to submit this for .24 as the basis for a
unified paravirt_ops. Any objections? ]
Currently, the set_lazy_mode pv_op is overloaded with 5 functions:
1. enter lazy cpu mode
2. leave lazy cpu mode
3. enter lazy mmu mode
4. leave lazy mmu mode
5. flush pending batched operations
This
2007 Oct 09
0
[PATCH RFC REPOST 2/2] paravirt: clean up lazy mode handling
[ I think this is a straight repost this patch, which addresses all the
previous comments. I'd like to submit this for .24 as the basis for a
unified paravirt_ops. Any objections? ]
Currently, the set_lazy_mode pv_op is overloaded with 5 functions:
1. enter lazy cpu mode
2. leave lazy cpu mode
3. enter lazy mmu mode
4. leave lazy mmu mode
5. flush pending batched operations
This
2012 Apr 10
7
[PATCH v3 1/2] xen: enter/exit lazy_mmu_mode around m2p_override calls
This patch is a significant performance improvement for the
m2p_override: about 6% using the gntdev device.
Each m2p_add/remove_override call issues a MULTI_grant_table_op and a
__flush_tlb_single if kmap_op != NULL. Batching all the calls together
is a great performance benefit because it means issuing one hypercall
total rather than two hypercall per page.
If paravirt_lazy_mode is set
2003 Aug 22
3
PAE removal patch for testing
If you're one of the people who has cvsup'd to 4.8-stable since August 8th
and you've since begun to experience panics on a previously stable system,
please apply the attached patch and see if your previous stability has
been restored.
Please tell me your results.
Thanks,
Mike "Silby" Silbersack
-------------- next part --------------
diff -u -r
2007 Apr 18
2
pte_offset_map + lazy mmu
Is pte_offset_map allowed to happen within lazy mmu? I presume not,
because you definitely don't want the mapping pte update to be deferred.
Or, more specifically, is kunmap_atomic ever allowed within lazy mmu?
I'm looking at kpte_clear_flush; I've already got a patch which turns
this into a pv_op, along with a Xen implementation. But I think its
probably an excess pv_op for a
2007 Apr 18
2
pte_offset_map + lazy mmu
Is pte_offset_map allowed to happen within lazy mmu? I presume not,
because you definitely don't want the mapping pte update to be deferred.
Or, more specifically, is kunmap_atomic ever allowed within lazy mmu?
I'm looking at kpte_clear_flush; I've already got a patch which turns
this into a pv_op, along with a Xen implementation. But I think its
probably an excess pv_op for a
2007 Apr 18
15
[PATCH 0 of 13] Basic infrastructure patches for a paravirtualized kernel
[ REPOST: Apologies to anyone who has seen this before. It
didn't make it onto any of the lists it should have. -J ]
Hi Andrew,
This series of patches lays the basic ground work for the
paravirtualized kernel patches coming later on. I think this lot is
ready for the rough-and-tumble world of the -mm tree.
For the most part, these patches do nothing or very little. The
patches should
2007 Apr 18
15
[PATCH 0 of 13] Basic infrastructure patches for a paravirtualized kernel
[ REPOST: Apologies to anyone who has seen this before. It
didn't make it onto any of the lists it should have. -J ]
Hi Andrew,
This series of patches lays the basic ground work for the
paravirtualized kernel patches coming later on. I think this lot is
ready for the rough-and-tumble world of the -mm tree.
For the most part, these patches do nothing or very little. The
patches should
2007 Apr 18
0
[PATCH 2/6] Paravirt CPU hypercall batching mode
The VMI ROM has a mode where hypercalls can be queued and batched. This turns
out to be a significant win during context switch, but must be done at a
specific point before side effects to CPU state are visible to subsequent
instructions. This is similar to the MMU batching hooks already provided.
The same hooks could be used by the Xen backend to implement a context switch
multicall.
To
2007 Apr 18
0
[PATCH 2/6] Paravirt CPU hypercall batching mode
The VMI ROM has a mode where hypercalls can be queued and batched. This turns
out to be a significant win during context switch, but must be done at a
specific point before side effects to CPU state are visible to subsequent
instructions. This is similar to the MMU batching hooks already provided.
The same hooks could be used by the Xen backend to implement a context switch
multicall.
To
2006 Jul 25
18
[PATCH] turn off writable page tables
At OLS I gave a talk on some of the Xen scalability inhibitors, and one
of these was writable page tables. We went over why the feature does
not scale, but just as important, we found that the uniprocessor case
does not provide any advantage either. These tests were done on x86_64,
so I wanted to run the 1-way test on 32 bit to show the same problem.
So, I have run with writable PTs and
2007 Apr 18
2
[PATCH 2/5] Paravirt cpu batching.patch
The VMI ROM has a mode where hypercalls can be queued and batched. This turns
out to be a significant win during context switch, but must be done at a
specific point before side effects to CPU state are visible to subsequent
instructions. This is similar to the MMU batching hooks already provided.
The same hooks could be used by the Xen backend to implement a context switch
multicall.
To
2007 Apr 18
2
[PATCH 2/5] Paravirt cpu batching.patch
The VMI ROM has a mode where hypercalls can be queued and batched. This turns
out to be a significant win during context switch, but must be done at a
specific point before side effects to CPU state are visible to subsequent
instructions. This is similar to the MMU batching hooks already provided.
The same hooks could be used by the Xen backend to implement a context switch
multicall.
To
2011 Sep 01
3
DOM0 Hang on a large box....
Hi,
I''m looking at a system hang on a large box: 160 cpus, 2TB. Dom0 is
booted with 160 vcpus (don''t ask me why :)), and an HVM guest is started
with over 1.5T RAM and 128 vcpus. The system hangs without much activity
after couple hours. Xen 4.0.2 and 2.6.32 based 64bit dom0.
During hang I discovered:
Most of dom0 vcpus are in double_lock_balance spinning on one of the locks:
2010 Mar 29
0
Interesting lockdep message coming out of blktap
I''m getting this:
blktap_validate_params: aio:/dev/vg_lilith-raid/xen-f13-64: capacity: 20971520, sector-size: 512
blktap_validate_params: aio:/dev/vg_lilith-raid/xen-f13-64: capacity: 20971520, sector-size: 512
blktap_device_create: minor 0 sectors 20971520 sector-size 512
blktap_device_create: creation of 253:0: 0
INFO: trying to register non-static key.
the code is fine but needs