Hi Konstantin,
I tested your patch. It was no problem.
Thank you for your kind correspondence.
Regards,
Kohji Okuno
> On Sat, Oct 04, 2014 at 05:53:26PM +0900, Kohji Okuno wrote:
>> Hi, Konstantin,
>>
>> > At the end of the mail is commit candidate. I did not even compiled this.
>> > Can you
Hi Konstantin,
Thank you very much for your detailed explanatin.
I understood the policy of vmem.
Many thanks,
Kohji Okuno
> On Sun, Oct 05, 2014 at 01:15:12PM +0900, Kohji Okuno wrote:
>> Hi,
>>
>> > On Sat, Oct 04, 2014 at 08:53:35PM +0900, Kohji Okuno wrote:
>> >> Hi Konstantin,
>> >>
>> >
On Sun, Oct 05, 2014 at 01:15:12PM +0900, Kohji Okuno wrote:
> Hi,
>
> > On Sat, Oct 04, 2014 at 08:53:35PM +0900, Kohji Okuno wrote:
> >> Hi Konstantin,
> >>
> >> Thank you for your prompt response.
> >> I will test and report from next monday.
> >>
> >> >> In addtion, I have one question.
> >>
Hi,
> On Sat, Oct 04, 2014 at 08:53:35PM +0900, Kohji Okuno wrote:
>> Hi Konstantin,
>>
>> Thank you for your prompt response.
>> I will test and report from next monday.
>>
>> >> In addtion, I have one question.
>> >> In current and 10-stable, is vm_map_delete() called by kva_free()?
>> > No, k
On Sat, Oct 04, 2014 at 08:53:35PM +0900, Kohji Okuno wrote:
> Hi Konstantin,
>
> Thank you for your prompt response.
> I will test and report from next monday.
>
> >> In addtion, I have one question.
> >> In current and 10-stable, is vm_map_delete() called by kva_free()?
> > No, kva_free() only
Hi Konstantin,
Thank you for your prompt response.
I will test and report from next monday.
>> In addtion, I have one question.
>> In current and 10-stable, is vm_map_delete() called by kva_free()?
> No, kva_free() only releases the vmem backing, leaving the page
> tables intact. This is why I o
On Sat, Oct 04, 2014 at 05:53:26PM +0900, Kohji Okuno wrote:
> Hi, Konstantin,
>
> > At the end of the mail is commit candidate. I did not even compiled this.
> > Can you test and report back, please ?
>
> Could you check the following?
> (1) should use kernel_pmap->pm_stats.resident_count
>
Hi, Konstantin,
> At the end of the mail is commit candidate. I did not even compiled this.
> Can you test and report back, please ?
Could you check the following?
(1) should use kernel_pmap->pm_stats.resident_count
^^^
I'm sorry. My patch was wrong.
(2) should us
On Sat, Oct 04, 2014 at 05:00:36PM +0900, Kohji Okuno wrote:
> Hi, Konstantin,
>
> Thank you for your comment.
> And, your change is better than mine.
At the end of the mail is commit candidate. I did not even compiled this.
Can you test and report back, please ?
>
> > Do you mean that this pan
Hi, Konstantin,
Thank you for your comment.
And, your change is better than mine.
> Do you mean that this panic is related to missed pmap_remove() ?
> I doubt it, since pmap_mapdev() does not establish managed mappings.
Yes, pmap_mapdev() does not establish managed mappings. But, if
kernel_pmap.
On Fri, Oct 03, 2014 at 05:25:33PM +0900, Kohji Okuno wrote:
> Hi,
>
> At least in i386 && 9-stable, when we call pmap_mapdev() and
> pmap_unmapdev(), kernel_pmap.pm_stats.resident_count is decreased
> incorrectly.
>
> pmap_mapdev_attr()->pmap_kenter_attr():
> In this path, kernel_pmap.pm_stats.r
Hi,
At least in i386 && 9-stable, when we call pmap_mapdev() and
pmap_unmapdev(), kernel_pmap.pm_stats.resident_count is decreased
incorrectly.
pmap_mapdev_attr()->pmap_kenter_attr():
In this path, kernel_pmap.pm_stats.resident_count is not increlmented.
pmap_unmapdev()->kmem_free(kernel_map)->v
12 matches
Mail list logo
