Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

On Thursday 15 June 2017 02:18 PM, Kirill A. Shutemov wrote: O I am not suggesting we don't do the invalidate (the need for that is documented in __split_huge_pmd_locked(). I am suggesting we need a new interface, something like Andrea suggested. old_pmd = pmdp_establish(pmd_mknotpresent());

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

On Thursday 15 June 2017 02:18 PM, Kirill A. Shutemov wrote: O I am not suggesting we don't do the invalidate (the need for that is documented in __split_huge_pmd_locked(). I am suggesting we need a new interface, something like Andrea suggested. old_pmd = pmdp_establish(pmd_mknotpresent());

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

On Thu, Jun 15, 2017 at 06:35:21AM +0530, Aneesh Kumar K.V wrote: > > > On Wednesday 14 June 2017 10:25 PM, Will Deacon wrote: > > Hi Aneesh, > > > > On Wed, Jun 14, 2017 at 08:55:26PM +0530, Aneesh Kumar K.V wrote: > > > On Wednesday 14 June 2017 07:21 PM, Kirill A. Shutemov wrote: > > > >

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

On Thu, Jun 15, 2017 at 06:35:21AM +0530, Aneesh Kumar K.V wrote: > > > On Wednesday 14 June 2017 10:25 PM, Will Deacon wrote: > > Hi Aneesh, > > > > On Wed, Jun 14, 2017 at 08:55:26PM +0530, Aneesh Kumar K.V wrote: > > > On Wednesday 14 June 2017 07:21 PM, Kirill A. Shutemov wrote: > > > >

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

On Thursday 15 June 2017 06:35 AM, Aneesh Kumar K.V wrote: W.r.t pmdp_invalidate() usage, I was wondering whether we can do that early in __split_huge_pmd_locked(). BTW by moving pmdp_invalidate early, we can then get rid of pmdp_huge_split_prepare(vma, haddr, pmd);

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

On Thursday 15 June 2017 06:35 AM, Aneesh Kumar K.V wrote: W.r.t pmdp_invalidate() usage, I was wondering whether we can do that early in __split_huge_pmd_locked(). BTW by moving pmdp_invalidate early, we can then get rid of pmdp_huge_split_prepare(vma, haddr, pmd);

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

On Wednesday 14 June 2017 10:30 PM, Vlastimil Babka wrote: On 06/14/2017 06:55 PM, Will Deacon wrote: May be we should relook at pmd PTE udpate interface. We really need an interface that can update pmd entries such that we don't clear it in between. IMHO, we can avoid the pmdp_invalidate()

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

On Wednesday 14 June 2017 10:30 PM, Vlastimil Babka wrote: On 06/14/2017 06:55 PM, Will Deacon wrote: May be we should relook at pmd PTE udpate interface. We really need an interface that can update pmd entries such that we don't clear it in between. IMHO, we can avoid the pmdp_invalidate()

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

On Wednesday 14 June 2017 10:25 PM, Will Deacon wrote: Hi Aneesh, On Wed, Jun 14, 2017 at 08:55:26PM +0530, Aneesh Kumar K.V wrote: On Wednesday 14 June 2017 07:21 PM, Kirill A. Shutemov wrote: Vlastimil noted that pmdp_invalidate() is not atomic and we can loose dirty and access bits if

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

On Wednesday 14 June 2017 10:25 PM, Will Deacon wrote: Hi Aneesh, On Wed, Jun 14, 2017 at 08:55:26PM +0530, Aneesh Kumar K.V wrote: On Wednesday 14 June 2017 07:21 PM, Kirill A. Shutemov wrote: Vlastimil noted that pmdp_invalidate() is not atomic and we can loose dirty and access bits if

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

On 06/14/2017 06:55 PM, Will Deacon wrote: >> >> May be we should relook at pmd PTE udpate interface. We really need an >> interface that can update pmd entries such that we don't clear it in >> between. IMHO, we can avoid the pmdp_invalidate() completely, if we can >> switch from a pmd PTE entry

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

On 06/14/2017 06:55 PM, Will Deacon wrote: >> >> May be we should relook at pmd PTE udpate interface. We really need an >> interface that can update pmd entries such that we don't clear it in >> between. IMHO, we can avoid the pmdp_invalidate() completely, if we can >> switch from a pmd PTE entry

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

Hi Aneesh, On Wed, Jun 14, 2017 at 08:55:26PM +0530, Aneesh Kumar K.V wrote: > On Wednesday 14 June 2017 07:21 PM, Kirill A. Shutemov wrote: > >Vlastimil noted that pmdp_invalidate() is not atomic and we can loose > >dirty and access bits if CPU sets them after pmdp dereference, but > >before

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

Hi Aneesh, On Wed, Jun 14, 2017 at 08:55:26PM +0530, Aneesh Kumar K.V wrote: > On Wednesday 14 June 2017 07:21 PM, Kirill A. Shutemov wrote: > >Vlastimil noted that pmdp_invalidate() is not atomic and we can loose > >dirty and access bits if CPU sets them after pmdp dereference, but > >before

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

On Wednesday 14 June 2017 07:21 PM, Kirill A. Shutemov wrote: Hi, Vlastimil noted that pmdp_invalidate() is not atomic and we can loose dirty and access bits if CPU sets them after pmdp dereference, but before set_pmd_at(). The bug doesn't lead to user-visible misbehaviour in current kernel,

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

On Wednesday 14 June 2017 07:21 PM, Kirill A. Shutemov wrote: Hi, Vlastimil noted that pmdp_invalidate() is not atomic and we can loose dirty and access bits if CPU sets them after pmdp dereference, but before set_pmd_at(). The bug doesn't lead to user-visible misbehaviour in current kernel,

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

Hi Kirill, On Wed, 14 Jun 2017 16:51:40 +0300 "Kirill A. Shutemov" wrote: > Vlastimil noted that pmdp_invalidate() is not atomic and we can loose > dirty and access bits if CPU sets them after pmdp dereference, but > before set_pmd_at(). > > The bug doesn't

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

Hi Kirill, On Wed, 14 Jun 2017 16:51:40 +0300 "Kirill A. Shutemov" wrote: > Vlastimil noted that pmdp_invalidate() is not atomic and we can loose > dirty and access bits if CPU sets them after pmdp dereference, but > before set_pmd_at(). > > The bug doesn't lead to user-visible misbehaviour in

[HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

Hi, Vlastimil noted that pmdp_invalidate() is not atomic and we can loose dirty and access bits if CPU sets them after pmdp dereference, but before set_pmd_at(). The bug doesn't lead to user-visible misbehaviour in current kernel, but fixing this would be critical for future work on THP: both

[HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

Hi, Vlastimil noted that pmdp_invalidate() is not atomic and we can loose dirty and access bits if CPU sets them after pmdp dereference, but before set_pmd_at(). The bug doesn't lead to user-visible misbehaviour in current kernel, but fixing this would be critical for future work on THP: both

Re: not needed patch

On Thursday 20 December 2007 06:29:06 am Ingo Molnar wrote: > > * Yinghai Lu <[EMAIL PROTECTED]> wrote: > > > Ingo. > > > > commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9 is not needed. another > > patch (by you !! commit 699d934d5f958d7944d195c03c334f28cc0b3669 x86: > > fixup cpu_info array

Re: not needed patch

Ingo Molnar wrote: > * Mike Travis <[EMAIL PROTECTED]> wrote: > by revert commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9, we could use c->cpu_index in identify_cpu. >>> but that's 2.6.25 stuff, right? Travis? >>> >> Looking at this more closely, yes my change is not needed and should

Re: not needed patch

* Mike Travis <[EMAIL PROTECTED]> wrote: > >> by revert commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9, we could > >> use c->cpu_index in identify_cpu. > > > > but that's 2.6.25 stuff, right? Travis? > > > > Looking at this more closely, yes my change is not needed and should > be removed.

Re: not needed patch

Ingo Molnar wrote: > * Yinghai Lu <[EMAIL PROTECTED]> wrote: > >> Ingo. >> >> commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9 is not needed. another >> patch (by you !! commit 699d934d5f958d7944d195c03c334f28cc0b3669 x86: >> fixup cpu_info array conversion) already removed clearing of >>

Re: not needed patch

Ingo Molnar wrote: > * Yinghai Lu <[EMAIL PROTECTED]> wrote: > >> Ingo. >> >> commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9 is not needed. another >> patch (by you !! commit 699d934d5f958d7944d195c03c334f28cc0b3669 x86: >> fixup cpu_info array conversion) already removed clearing of >>

Re: not needed patch

* Yinghai Lu <[EMAIL PROTECTED]> wrote: > Ingo. > > commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9 is not needed. another > patch (by you !! commit 699d934d5f958d7944d195c03c334f28cc0b3669 x86: > fixup cpu_info array conversion) already removed clearing of > c->cpu_index. in identify_cpu >

Re: not needed patch

* Yinghai Lu [EMAIL PROTECTED] wrote: Ingo. commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9 is not needed. another patch (by you !! commit 699d934d5f958d7944d195c03c334f28cc0b3669 x86: fixup cpu_info array conversion) already removed clearing of c-cpu_index. in identify_cpu also it is

Re: not needed patch

Ingo Molnar wrote: * Yinghai Lu [EMAIL PROTECTED] wrote: Ingo. commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9 is not needed. another patch (by you !! commit 699d934d5f958d7944d195c03c334f28cc0b3669 x86: fixup cpu_info array conversion) already removed clearing of c-cpu_index. in

Re: not needed patch

Ingo Molnar wrote: * Yinghai Lu [EMAIL PROTECTED] wrote: Ingo. commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9 is not needed. another patch (by you !! commit 699d934d5f958d7944d195c03c334f28cc0b3669 x86: fixup cpu_info array conversion) already removed clearing of c-cpu_index. in

Re: not needed patch

* Mike Travis [EMAIL PROTECTED] wrote: by revert commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9, we could use c-cpu_index in identify_cpu. but that's 2.6.25 stuff, right? Travis? Looking at this more closely, yes my change is not needed and should be removed. I'm not sure

Re: not needed patch

Ingo Molnar wrote: * Mike Travis [EMAIL PROTECTED] wrote: by revert commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9, we could use c-cpu_index in identify_cpu. but that's 2.6.25 stuff, right? Travis? Looking at this more closely, yes my change is not needed and should be removed. I'm

Re: not needed patch

On Thursday 20 December 2007 06:29:06 am Ingo Molnar wrote: * Yinghai Lu [EMAIL PROTECTED] wrote: Ingo. commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9 is not needed. another patch (by you !! commit 699d934d5f958d7944d195c03c334f28cc0b3669 x86: fixup cpu_info array conversion)

not needed patch

Ingo. commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9 is not needed. another patch (by you !! commit 699d934d5f958d7944d195c03c334f28cc0b3669 x86: fixup cpu_info array conversion) already removed clearing of c->cpu_index. in identify_cpu also it is not consisent to smpboot_32.c. (it will

not needed patch

Ingo. commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9 is not needed. another patch (by you !! commit 699d934d5f958d7944d195c03c334f28cc0b3669 x86: fixup cpu_info array conversion) already removed clearing of c-cpu_index. in identify_cpu also it is not consisent to smpboot_32.c. (it will