On 03/31/2012 12:07 AM, Thomas Gleixner wrote:
On Fri, 30 Mar 2012, H. Peter Anvin wrote:
What is the current status of this patchset? I haven't looked at it too
closely because I have been focused on 3.4 up until now...
The real question is whether these heuristics are the correct approach
o
On 03/31/2012 07:54 AM, Asai Thambi Samymuthu Pattrayasamy
(asamymuthupa) [CONT - Type 2] wrote:
On 3/30/2012 2:53 AM, Ren Mingxin wrote:
Currently, block core has been supplied "disk_name_format()", so
we should remove duplicate function "rssd_disk_name_format()"
and use the new function to
On 03/30/2012 11:28 PM, Tejun Heo wrote:
On Fri, Mar 30, 2012 at 08:26:06AM -0700, Tejun Heo wrote:
On Fri, Mar 30, 2012 at 05:53:52PM +0800, Ren Mingxin wrote:
The current virtblk's naming algorithm only supports 263 disks.
If there are mass of virtblks(exceeding 263), there will be disks
On 03/30/2012 11:38 PM, Tejun Heo wrote:
On Fri, Mar 30, 2012 at 08:26:06AM -0700, Tejun Heo wrote:
On Fri, Mar 30, 2012 at 05:53:52PM +0800, Ren Mingxin wrote:
The current virtblk's naming algorithm only supports 263 disks.
If there are mass of virtblks(exceeding 263), there will be disks
https://bugzilla.kernel.org/show_bug.cgi?id=42779
--- Comment #25 from madenginee...@gmail.com 2012-04-01 23:40:21 ---
Created an attachment (id=72789)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72789)
Last 10k lines of a trace showing the fault, kernel 3.3rc5 with patches
--
Confi
https://bugzilla.kernel.org/show_bug.cgi?id=42779
--- Comment #24 from madenginee...@gmail.com 2012-04-01 23:39:47 ---
Created an attachment (id=72788)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72788)
Register state and code disassembly at failure point, kernel 3.3rc5 with
patches
https://bugzilla.kernel.org/show_bug.cgi?id=42779
--- Comment #23 from madenginee...@gmail.com 2012-04-01 23:38:21 ---
Now it dies in a different place, still with a movq instruction (movq
(%edx),%mm0). I think the difference is because of a configuration change or
package update since the
On Sun, Apr 01, 2012 at 03:38:37PM +0300, Avi Kivity wrote:
> On 03/30/2012 03:01 PM, Paul Mackerras wrote:
> > I just noticed that the branch you asked Linus to pull includes none
> > of the patches that Alex sent you in the last batch, in the email with
> > subject "[PULL 00/56] ppc patch queue 2
On Sun, 2012-04-01 at 15:38 +0300, Avi Kivity wrote:
> On 03/30/2012 03:01 PM, Paul Mackerras wrote:
> > I just noticed that the branch you asked Linus to pull includes none
> > of the patches that Alex sent you in the last batch, in the email with
> > subject "[PULL 00/56] ppc patch queue 2012-03-
Alexander Graf writes:
> @@ -662,6 +668,13 @@ static int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu
> *vcpu,
> int r = -EINVAL;
>
> switch (reg->id) {
> +#ifdef CONFIG_PPC_BOOK3S
> + case KVM_ONE_REG_PPC_HIOR:
> + r = get_user(to_book3s(vcpu)->hior, (u64 __user *)re
On 03/29/2012 11:27 AM, Xiao Guangrong wrote:
> If the the present bit of page fault error code is set, it indicates
> the shadow page is populated on all levels, it means what we do is only
> modify the access bit which can be done out of mmu-lock
>
> The tricks in this patch is avoiding the race
On 03/29/2012 11:25 AM, Xiao Guangrong wrote:
> It depends on PTE_LIST_WRITE_PROTECT bit in rmap which let us quickly know
> whether the page is writable out of mmu-lock
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/kvm/mmu.c | 17 +
> arch/x86/kvm/paging_tmpl.h |
On 03/29/2012 11:25 AM, Xiao Guangrong wrote:
> Using PTE_LIST_WRITE_PROTECT bit in rmap store the write-protect status to
> avoid unnecessary shadow page walking
>
> Also if no shadow page is indirect, the page is write-free
>
>
> @@ -2262,6 +2291,9 @@ static int mmu_need_write_protect(struct kvm_
https://bugzilla.kernel.org/show_bug.cgi?id=42779
--- Comment #22 from Avi Kivity 2012-04-01 14:15:51 ---
No guarantees of course, but this is just 3.3-rc5 with a few patches on top.
It should be fine for a short test.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=em
On 04/01/2012 07:23 PM, Avi Kivity wrote:
On 04/01/2012 04:48 PM, Raghavendra K T wrote:
I have patch something like below in mind to try:
I'm interested in how PLE does vs. your patches, both with PLE enabled
and disabled.
Sure. will update with the experimental results.
--
To unsubscribe
On 04/01/2012 04:48 PM, Raghavendra K T wrote:
>>> I have patch something like below in mind to try:
>>>
>>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>>> index d3b98b1..5127668 100644
>>> --- a/virt/kvm/kvm_main.c
>>> +++ b/virt/kvm/kvm_main.c
>>> @@ -1608,15 +1608,18 @@ void kvm_vcpu
On 04/01/2012 06:48 PM, Avi Kivity wrote:
On 03/30/2012 01:07 PM, Raghavendra K T wrote:
On 03/29/2012 11:33 PM, Raghavendra K T wrote:
On 03/29/2012 03:28 PM, Avi Kivity wrote:
On 03/28/2012 08:21 PM, Raghavendra K T wrote:
I really like below ideas. Thanks for that!.
- from the PLE hand
On 03/31/2012 01:07 AM, Thomas Gleixner wrote:
> On Fri, 30 Mar 2012, H. Peter Anvin wrote:
>
> > What is the current status of this patchset? I haven't looked at it too
> > closely because I have been focused on 3.4 up until now...
>
> The real question is whether these heuristics are the correct
On 03/30/2012 01:07 PM, Raghavendra K T wrote:
> On 03/29/2012 11:33 PM, Raghavendra K T wrote:
>> On 03/29/2012 03:28 PM, Avi Kivity wrote:
>>> On 03/28/2012 08:21 PM, Raghavendra K T wrote:
>
>> I really like below ideas. Thanks for that!.
>>
>>> - from the PLE handler, don't wake up a vcpu that
On 03/30/2012 12:18 PM, Xiao Guangrong wrote:
> On 03/29/2012 08:57 PM, Avi Kivity wrote:
>
> > On 03/29/2012 01:40 PM, Xiao Guangrong wrote:
> * Implementation
> We can freely walk the page between walk_shadow_page_lockless_begin and
> walk_shadow_page_lockless_end, it can ensure al
On 03/30/2012 08:01 AM, Xiao Guangrong wrote:
> On 03/29/2012 09:07 PM, Avi Kivity wrote:
>
> > On 03/29/2012 11:22 AM, Xiao Guangrong wrote:
> >> It can calculate the base gpa of the specified shadow page on any level,
> >> let it instead of FNAME(get_level1_sp_gpa)
> >>
> >>
> >> +static gpa_t FN
On 03/30/2012 03:01 PM, Paul Mackerras wrote:
> I just noticed that the branch you asked Linus to pull includes none
> of the patches that Alex sent you in the last batch, in the email with
> subject "[PULL 00/56] ppc patch queue 2012-03-15" sent on March 15,
> where he asked you to pull git://gith
On Fri, Mar 30, 2012 at 05:50:12PM +0800, Ren Mingxin wrote:
>
>
> This patch series renames "sd_format_disk_name()" to
> "disk_name_format()" and moves it into block core. So
> that who needs formatting disk name can use it, instead
> of duplicating these similar help functions.
I see there are
On Sat, Mar 31, 2012 at 12:15:34AM +0200, Jan Kiszka wrote:
> On 2012-03-30 23:09, Alex Williamson wrote:
> > On Fri, 2012-03-30 at 22:35 +0200, Jan Kiszka wrote:
> >> On 2012-03-30 22:31, Jason Baron wrote:
> >>> On Fri, Mar 30, 2012 at 10:18:31PM +0200, Jan Kiszka wrote:
> >>> The root cause
On Fri, Mar 30, 2012 at 11:24:10AM +0800, Asias He wrote:
> Benchmark shows small performance improvement on fusion io device.
>
> Before:
> seq-read : io=1,024MB, bw=19,982KB/s, iops=39,964, runt= 52475msec
> seq-write: io=1,024MB, bw=20,321KB/s, iops=40,641, runt= 51601msec
> rnd-read : io
25 matches
Mail list logo
