On 18-11-21 17:47:07, Will Deacon wrote:
> > + /*
> > +* The arm64 boot protocol mandates that CNTFRQ_EL0 reflects
> > +* the timer frequency. To avoid breakage on misconfigured
> > +* systems, do not register the early sched_clock if the
> > +* programmed value if zero. Other
On 18-11-20 14:55:23, Marc Zyngier wrote:
> > Yeah, I saw 56 is used in arm_arch_timer.c, but I could not find where
> > this minimum is defined in aarch64 specs. I will change it to 56.
>
> See D10.1.2 (The system counter) in the ARM ARM[1], which says:
>
>
> The Generic Timer provides a
On 18-11-20 14:55:23, Marc Zyngier wrote:
> > Yeah, I saw 56 is used in arm_arch_timer.c, but I could not find where
> > this minimum is defined in aarch64 specs. I will change it to 56.
>
> See D10.1.2 (The system counter) in the ARM ARM[1], which says:
>
>
> The Generic Timer provides a
Allow printk time stamps/sched_clock() to be available from the early
boot.
Signed-off-by: Pavel Tatashin
---
arch/arm64/kernel/setup.c| 25 +
drivers/clocksource/arm_arch_timer.c | 8
include/clocksource/arm_arch_timer.h | 3 +++
3 files changed
Allow printk time stamps/sched_clock() to be available from the early
boot.
Signed-off-by: Pavel Tatashin
---
arch/arm64/kernel/setup.c| 25 +
drivers/clocksource/arm_arch_timer.c | 8
include/clocksource/arm_arch_timer.h | 3 +++
3 files changed
considering this is
only 60G domain.
Pavel Tatashin (1):
arm64: Early boot time stamps
arch/arm64/kernel/setup.c| 25 +
drivers/clocksource/arm_arch_timer.c | 8
include/clocksource/arm_arch_timer.h | 3 +++
3 files changed, 32 insertions(+), 4
considering this is
only 60G domain.
Pavel Tatashin (1):
arm64: Early boot time stamps
arch/arm64/kernel/setup.c| 25 +
drivers/clocksource/arm_arch_timer.c | 8
include/clocksource/arm_arch_timer.h | 3 +++
3 files changed, 32 insertions(+), 4
> > +static __init void sched_clock_early_init(void)
> > +{
> > + u64 freq = arch_timer_get_cntfrq();
> > + u64 (*read_time)(void) = arch_counter_get_cntvct;
>
> We already have arch_timer_read_counter which is exposed from
> arm_arch_timer.h.
OK
>
> > +
> > + /* Early clock is
> > +static __init void sched_clock_early_init(void)
> > +{
> > + u64 freq = arch_timer_get_cntfrq();
> > + u64 (*read_time)(void) = arch_counter_get_cntvct;
>
> We already have arch_timer_read_counter which is exposed from
> arm_arch_timer.h.
OK
>
> > +
> > + /* Early clock is
of pages with the current code). Should we ever get a
> report that offlining takes too long to react on fatal signal then we
> should rather fix the core migration to use killable waits and bailout
> on a signal.
>
> Signed-off-by: Michal Hocko
Looks good to me, I also do not
of pages with the current code). Should we ever get a
> report that offlining takes too long to react on fatal signal then we
> should rather fix the core migration to use killable waits and bailout
> on a signal.
>
> Signed-off-by: Michal Hocko
Looks good to me, I also do not
/3pJ5kgJHyN
dmesg after:
https://paste.ubuntu.com/p/RHKGVd9nSM
As seen from the above with base smp_init is finished after 0.47s:
[0.464585] SMP: Total of 8 processors activated.
But, in reality, 3.2s is missing which is a quiet long considering this is
only 60G domain.
Pavel Tatashin (1):
arm64
/3pJ5kgJHyN
dmesg after:
https://paste.ubuntu.com/p/RHKGVd9nSM
As seen from the above with base smp_init is finished after 0.47s:
[0.464585] SMP: Total of 8 processors activated.
But, in reality, 3.2s is missing which is a quiet long considering this is
only 60G domain.
Pavel Tatashin (1):
arm64
Allow printk time stamps/sched_clock() to be available from the early
boot.
Signed-off-by: Pavel Tatashin
---
arch/arm64/kernel/setup.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index f4fc1e0544b7..4df41a66b403
Allow printk time stamps/sched_clock() to be available from the early
boot.
Signed-off-by: Pavel Tatashin
---
arch/arm64/kernel/setup.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index f4fc1e0544b7..4df41a66b403
l the values being updated to be in sync.
>
> Signed-off-by: Arun KS
> Reviewed-by: Konstantin Khlebnikov
> Acked-by: Michal Hocko
> Acked-by: Vlastimil Babka
Reviewed-by: Pavel Tatashin
l the values being updated to be in sync.
>
> Signed-off-by: Arun KS
> Reviewed-by: Konstantin Khlebnikov
> Acked-by: Michal Hocko
> Acked-by: Vlastimil Babka
Reviewed-by: Pavel Tatashin
ikov
> Acked-by: Michal Hocko
> Acked-by: Vlastimil Babka
Reviewed-by: Pavel Tatashin
ikov
> Acked-by: Michal Hocko
> Acked-by: Vlastimil Babka
Reviewed-by: Pavel Tatashin
-off-by: Arun KS
> Reviewed-by: Konstantin Khlebnikov
> Acked-by: Michal Hocko
> Acked-by: Vlastimil Babka
Reviewed-by: Pavel Tatashin
-off-by: Arun KS
> Reviewed-by: Konstantin Khlebnikov
> Acked-by: Michal Hocko
> Acked-by: Vlastimil Babka
Reviewed-by: Pavel Tatashin
pected behavior. There are no known bugs as a result of the current code
> but it is better to prevent from them in principle.
>
> Signed-off-by: Arun KS
> Reviewed-by: Konstantin Khlebnikov
> Acked-by: Michal Hocko
> Acked-by: Vlastimil Babka
Reviewed-by: Pavel Tatashin
pected behavior. There are no known bugs as a result of the current code
> but it is better to prevent from them in principle.
>
> Signed-off-by: Arun KS
> Reviewed-by: Konstantin Khlebnikov
> Acked-by: Michal Hocko
> Acked-by: Vlastimil Babka
Reviewed-by: Pavel Tatashin
> Wait, what? Can you name specific ones? Nowadays, enabling KSM for
> untrusted VMs seems like a terrible idea to me, security-wise.
Of course it is not used to share data among different
customers/tenants, as far as I know it is used by Oracle Cloud to
merge the same pages in clear containers.
> Wait, what? Can you name specific ones? Nowadays, enabling KSM for
> untrusted VMs seems like a terrible idea to me, security-wise.
Of course it is not used to share data among different
customers/tenants, as far as I know it is used by Oracle Cloud to
merge the same pages in clear containers.
uch sense to warn about too much memory for the l1tf mitigation
> when it is forcefully disabled by the administrator.
>
> Signed-off-by: Michal Hocko
Reviewed-by: Pavel Tatashin
uch sense to warn about too much memory for the l1tf mitigation
> when it is forcefully disabled by the administrator.
>
> Signed-off-by: Michal Hocko
Reviewed-by: Pavel Tatashin
>
> This collides with the refactoring of hmm, to be done in terms of
> devm_memremap_pages(). I'd rather not introduce another common
> function *beneath* hmm and devm_memremap_pages() and rather make
> devm_memremap_pages() the common function.
>
> I plan to resubmit that cleanup after
>
> This collides with the refactoring of hmm, to be done in terms of
> devm_memremap_pages(). I'd rather not introduce another common
> function *beneath* hmm and devm_memremap_pages() and rather make
> devm_memremap_pages() the common function.
>
> I plan to resubmit that cleanup after
_release_mem_region.
> + * HMM/devm take care to release their resources when they want,
> + * so if we are dealing with them, let us just back off here.
> + */
> + if (!(res->flags & IORESOURCE_SYSRAM)) {
> + r
_release_mem_region.
> + * HMM/devm take care to release their resources when they want,
> + * so if we are dealing with them, let us just back off here.
> + */
> + if (!(res->flags & IORESOURCE_SYSRAM)) {
> + r
ase
>
> One thing I do not know is whether we can move kasan calls out of the
> hotplug lock or not.
> If we can, we could move the hotplug lock within add/del_device_memory().
>
> Signed-off-by: Oscar Salvador
Looks good to me, thank you.
Reviewed-by: Pavel Tatashin
Pasha
ase
>
> One thing I do not know is whether we can move kasan calls out of the
> hotplug lock or not.
> If we can, we could move the hotplug lock within add/del_device_memory().
>
> Signed-off-by: Oscar Salvador
Looks good to me, thank you.
Reviewed-by: Pavel Tatashin
Pasha
Salvador
> Reviewed-by: David Hildenbrand
Reviewed-by: Pavel Tatashin
Salvador
> Reviewed-by: David Hildenbrand
Reviewed-by: Pavel Tatashin
= __next_pfn_valid_range(, (end_pfn)))
Can this be improved somehow? It took me a while to understand this
piece of code. i is actually end of block, and not an index by PFN, ({pfn = i -
count; 1;}) is
simply hard to parse. Why can't we make __next_pfn_valid_range() to
return both end and a start of a block?
The rest is good:
Reviewed-by: Pavel Tatashin
Thank you,
Pasha
= __next_pfn_valid_range(, (end_pfn)))
Can this be improved somehow? It took me a while to understand this
piece of code. i is actually end of block, and not an index by PFN, ({pfn = i -
count; 1;}) is
simply hard to parse. Why can't we make __next_pfn_valid_range() to
return both end and a start of a block?
The rest is good:
Reviewed-by: Pavel Tatashin
Thank you,
Pasha
m page
> size to 56 to support some powerpc64 configurations.
>
> This change should introduce no change on SPARC since it already had this
> code. In the case of x86_64 I saw a reduction from 3.75s to 2.80s when
> initializing 384GB of RAM per node. Pavel Tatashin tested on a sys
m page
> size to 56 to support some powerpc64 configurations.
>
> This change should introduce no change on SPARC since it already had this
> code. In the case of x86_64 I saw a reduction from 3.75s to 2.80s when
> initializing 384GB of RAM per node. Pavel Tatashin tested on a sys
On 10/17/18 12:31 PM, Alexander Duyck wrote:
> On 10/17/2018 8:40 AM, David Laight wrote:
>> From: Pavel Tatashin
>>> Sent: 17 October 2018 16:12
>>> On 10/17/18 11:07 AM, Alexander Duyck wrote:
>>>> On 10/17/2018 1:47 AM, Michal Hocko wrote:
>>
On 10/17/18 12:31 PM, Alexander Duyck wrote:
> On 10/17/2018 8:40 AM, David Laight wrote:
>> From: Pavel Tatashin
>>> Sent: 17 October 2018 16:12
>>> On 10/17/18 11:07 AM, Alexander Duyck wrote:
>>>> On 10/17/2018 1:47 AM, Michal Hocko wrote:
>>
On 10/17/18 11:07 AM, Alexander Duyck wrote:
> On 10/17/2018 1:47 AM, Michal Hocko wrote:
>> On Mon 15-10-18 13:26:56, Alexander Duyck wrote:
>>> This change makes it so that we use the same approach that was
>>> already in
>>> use on Sparc on all the archtectures that support a 64b long.
>>>
On 10/17/18 11:07 AM, Alexander Duyck wrote:
> On 10/17/2018 1:47 AM, Michal Hocko wrote:
>> On Mon 15-10-18 13:26:56, Alexander Duyck wrote:
>>> This change makes it so that we use the same approach that was
>>> already in
>>> use on Sparc on all the archtectures that support a 64b long.
>>>
On 10/16/18 4:49 PM, Alexander Duyck wrote:
> On 10/16/2018 1:33 PM, Pavel Tatashin wrote:
>>
>>
>> On 10/15/18 4:27 PM, Alexander Duyck wrote:
>>> As best as I can tell the meminit_pfn_in_nid call is completely
>>> redundant.
>>> The defe
On 10/16/18 4:49 PM, Alexander Duyck wrote:
> On 10/16/2018 1:33 PM, Pavel Tatashin wrote:
>>
>>
>> On 10/15/18 4:27 PM, Alexander Duyck wrote:
>>> As best as I can tell the meminit_pfn_in_nid call is completely
>>> redundant.
>>> The defe
On 10/15/18 4:27 PM, Alexander Duyck wrote:
> As best as I can tell the meminit_pfn_in_nid call is completely redundant.
> The deferred memory initialization is already making use of
> for_each_free_mem_range which in turn will call into __next_mem_range which
> will only return a memory range
On 10/15/18 4:27 PM, Alexander Duyck wrote:
> As best as I can tell the meminit_pfn_in_nid call is completely redundant.
> The deferred memory initialization is already making use of
> for_each_free_mem_range which in turn will call into __next_mem_range which
> will only return a memory range
On 10/15/18 4:26 PM, Alexander Duyck wrote:
> This change makes it so that we use the same approach that was already in
> use on Sparc on all the archtectures that support a 64b long.
>
> This is mostly motivated by the fact that 8 to 10 store/move instructions
> are likely always going to be
On 10/15/18 4:26 PM, Alexander Duyck wrote:
> This change makes it so that we use the same approach that was already in
> use on Sparc on all the archtectures that support a 64b long.
>
> This is mostly motivated by the fact that 8 to 10 store/move instructions
> are likely always going to be
impacted by this change there
> should be little to no negative impact. The main reason for that being
> the fact that the compiler can actually drop some of the writes by
> merging them with the later assignments.
>
> Thanks.
>
> - Alex
>
> On Sat, Oct 13, 2018 at 9:58 AM P
impacted by this change there
> should be little to no negative impact. The main reason for that being
> the fact that the compiler can actually drop some of the writes by
> merging them with the later assignments.
>
> Thanks.
>
> - Alex
>
> On Sat, Oct 13, 2018 at 9:58 AM P
This is incorrect: next_present_section_nr() returns "int" and -1 no
next section, this change would lead to infinite loop.
On Sat, Oct 13, 2018 at 12:16 PM Peng Hao wrote:
>
>
> From: Peng Hao
>
> In all use locations for for_each_present_section_nr, variable
> section_nr is unsigned. It is
This is incorrect: next_present_section_nr() returns "int" and -1 no
next section, this change would lead to infinite loop.
On Sat, Oct 13, 2018 at 12:16 PM Peng Hao wrote:
>
>
> From: Peng Hao
>
> In all use locations for for_each_present_section_nr, variable
> section_nr is unsigned. It is
I am worried about this change. I added SPARC optimized
mm_zero_struct_page() specifically to SPARC because it has a poor
performance with small memset()s, since it uses STBI instructions.
However, other architectures might not suffer with small memset()s,
and have hardware optimized memset
I am worried about this change. I added SPARC optimized
mm_zero_struct_page() specifically to SPARC because it has a poor
performance with small memset()s, since it uses STBI instructions.
However, other architectures might not suffer with small memset()s,
and have hardware optimized memset
Reviewed-by: Pavel Tatashin
On 10/2/18 10:38 AM, Masayoshi Mizuma wrote:
> From: Naoya Horiguchi
>
> There is a kernel panic that is triggered when reading /proc/kpageflags
> on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
>
> BUG: unable to handle ker
Reviewed-by: Pavel Tatashin
On 10/2/18 10:38 AM, Masayoshi Mizuma wrote:
> From: Naoya Horiguchi
>
> There is a kernel panic that is triggered when reading /proc/kpageflags
> on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
>
> BUG: unable to handle ker
I have not reviewed them yet. I am waiting for Masayoshi to send a new
series with correct order as Ingo requested.
Pavel
On 10/2/18 10:01 AM, Michal Hocko wrote:
> On Thu 27-09-18 22:41:36, Thomas Gleixner wrote:
>> On Tue, 25 Sep 2018, Masayoshi Mizuma wrote:
>>
>>> This patch series are the
I have not reviewed them yet. I am waiting for Masayoshi to send a new
series with correct order as Ingo requested.
Pavel
On 10/2/18 10:01 AM, Michal Hocko wrote:
> On Thu 27-09-18 22:41:36, Thomas Gleixner wrote:
>> On Tue, 25 Sep 2018, Masayoshi Mizuma wrote:
>>
>>> This patch series are the
On 10/2/18 10:01 AM, Michal Hocko wrote:
> On Thu 27-09-18 22:41:36, Thomas Gleixner wrote:
>> On Tue, 25 Sep 2018, Masayoshi Mizuma wrote:
>>
>>> This patch series are the fix for movable_node boot option
>>> issue which was introduced by commit 124049decbb1 ("x86/e820:
>>> put !E820_TYPE_RAM
On 10/2/18 10:01 AM, Michal Hocko wrote:
> On Thu 27-09-18 22:41:36, Thomas Gleixner wrote:
>> On Tue, 25 Sep 2018, Masayoshi Mizuma wrote:
>>
>>> This patch series are the fix for movable_node boot option
>>> issue which was introduced by commit 124049decbb1 ("x86/e820:
>>> put !E820_TYPE_RAM
On 8/16/18 9:35 PM, Pasha Tatashin wrote:
>
>
> On 7/6/18 5:01 AM, Jia He wrote:
>> Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
>> where possible") optimized the loop in memmap_init_zone(). But there is
>> still some room for improvement. E.g. in early_pfn_valid(),
On 8/16/18 9:35 PM, Pasha Tatashin wrote:
>
>
> On 7/6/18 5:01 AM, Jia He wrote:
>> Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
>> where possible") optimized the loop in memmap_init_zone(). But there is
>> still some room for improvement. E.g. in early_pfn_valid(),
> This tries to fix [1], which was reported by David Hildenbrand, and also
> does some cleanups/refactoring.
Hi Oscar,
I would like to review this work. Are you in process of sending a new version?
If so, I will wait for it.
Thank you,
Pavel
>
> I am sending this as RFC to see if the
> This tries to fix [1], which was reported by David Hildenbrand, and also
> does some cleanups/refactoring.
Hi Oscar,
I would like to review this work. Are you in process of sending a new version?
If so, I will wait for it.
Thank you,
Pavel
>
> I am sending this as RFC to see if the
On 07/31/2018 04:50 PM, Oscar Salvador wrote:
> On Tue, Jul 31, 2018 at 11:23:33AM -0400, Pavel Tatashin wrote:
>> Yes we free meminit when no CONFIG_MEMORY_HOTPLUG
>> See here:
>> http://src.illumos.org/source/xref/linux-master/include/asm-generic/vmlinux.lds.h#107
>
&
On 07/31/2018 04:50 PM, Oscar Salvador wrote:
> On Tue, Jul 31, 2018 at 11:23:33AM -0400, Pavel Tatashin wrote:
>> Yes we free meminit when no CONFIG_MEMORY_HOTPLUG
>> See here:
>> http://src.illumos.org/source/xref/linux-master/include/asm-generic/vmlinux.lds.h#107
>
&
early init, let us replace
> > __paginginit with __init, so their code gets freed up.
> >
> > Signed-off-by: Oscar Salvador
> > Reviewed-by: Pavel Tatashin
>
> Andrew, could you please fold the following cleanup into this patch?
> thanks
>
> Pavel, since this has y
early init, let us replace
> > __paginginit with __init, so their code gets freed up.
> >
> > Signed-off-by: Oscar Salvador
> > Reviewed-by: Pavel Tatashin
>
> Andrew, could you please fold the following cleanup into this patch?
> thanks
>
> Pavel, since this has y
Yes we free meminit when no CONFIG_MEMORY_HOTPLUG
See here:
http://src.illumos.org/source/xref/linux-master/include/asm-generic/vmlinux.lds.h#107
Pavel
On Tue, Jul 31, 2018 at 11:06 AM Pavel Tatashin
wrote:
>
> On Tue, Jul 31, 2018 at 11:01 AM Oscar Salvador
> wrote:
> >
>
Yes we free meminit when no CONFIG_MEMORY_HOTPLUG
See here:
http://src.illumos.org/source/xref/linux-master/include/asm-generic/vmlinux.lds.h#107
Pavel
On Tue, Jul 31, 2018 at 11:06 AM Pavel Tatashin
wrote:
>
> On Tue, Jul 31, 2018 at 11:01 AM Oscar Salvador
> wrote:
> >
>
On Tue, Jul 31, 2018 at 11:01 AM Oscar Salvador
wrote:
>
> On Tue, Jul 31, 2018 at 10:53:52AM -0400, Pavel Tatashin wrote:
> > Thats correct on arches where no sparsemem setup_usemap() will not be
> > freed up. It is a tiny function, just a few instructions. Not a big
>
On Tue, Jul 31, 2018 at 11:01 AM Oscar Salvador
wrote:
>
> On Tue, Jul 31, 2018 at 10:53:52AM -0400, Pavel Tatashin wrote:
> > Thats correct on arches where no sparsemem setup_usemap() will not be
> > freed up. It is a tiny function, just a few instructions. Not a big
>
Thats correct on arches where no sparsemem setup_usemap() will not be
freed up. It is a tiny function, just a few instructions. Not a big
deal.
Pavel
On Tue, Jul 31, 2018 at 10:51 AM Oscar Salvador
wrote:
>
> On Tue, Jul 31, 2018 at 10:45:45AM -0400, Pavel Tatashin wrote:
> > He
Thats correct on arches where no sparsemem setup_usemap() will not be
freed up. It is a tiny function, just a few instructions. Not a big
deal.
Pavel
On Tue, Jul 31, 2018 at 10:51 AM Oscar Salvador
wrote:
>
> On Tue, Jul 31, 2018 at 10:45:45AM -0400, Pavel Tatashin wrote:
> > He
On 18-07-31 16:41:57, Oscar Salvador wrote:
> On Tue, Jul 31, 2018 at 08:49:11AM -0400, Pavel Tatashin wrote:
> > Hi Oscar,
> >
> > Have you looked into replacing __paginginit via __meminit ? What is
> > the reason to keep both?
> Hi Pavel,
>
> Actually, thin
On 18-07-31 16:41:57, Oscar Salvador wrote:
> On Tue, Jul 31, 2018 at 08:49:11AM -0400, Pavel Tatashin wrote:
> > Hi Oscar,
> >
> > Have you looked into replacing __paginginit via __meminit ? What is
> > the reason to keep both?
> Hi Pavel,
>
> Actually, thin
On Tue, Jul 31, 2018 at 10:43 AM Pavel Tatashin
wrote:
>
> Hi Oscar,
>
> There is a simpler way. I will send it out in a bit. No need for your first
> function, only setup_usemap() needs to be changed to __ref.
I meant first patch not function :)
>
> Pavel
> On Tue,
On Tue, Jul 31, 2018 at 10:43 AM Pavel Tatashin
wrote:
>
> Hi Oscar,
>
> There is a simpler way. I will send it out in a bit. No need for your first
> function, only setup_usemap() needs to be changed to __ref.
I meant first patch not function :)
>
> Pavel
> On Tue,
Hi Oscar,
There is a simpler way. I will send it out in a bit. No need for your
first function, only setup_usemap() needs to be changed to __ref.
Pavel
On Tue, Jul 31, 2018 at 10:42 AM Oscar Salvador
wrote:
>
> On Tue, Jul 31, 2018 at 08:49:11AM -0400, Pavel Tatashin wrote:
> &
Hi Oscar,
There is a simpler way. I will send it out in a bit. No need for your
first function, only setup_usemap() needs to be changed to __ref.
Pavel
On Tue, Jul 31, 2018 at 10:42 AM Oscar Salvador
wrote:
>
> On Tue, Jul 31, 2018 at 08:49:11AM -0400, Pavel Tatashin wrote:
> &
Hi Oscar,
Have you looked into replacing __paginginit via __meminit ? What is
the reason to keep both?
Thank you,
Pavel
On Tue, Jul 31, 2018 at 8:45 AM wrote:
>
> From: Oscar Salvador
>
> __pagininit macro is being used to mark functions for:
>
> a) Functions that we do not need to keep once
Hi Oscar,
Have you looked into replacing __paginginit via __meminit ? What is
the reason to keep both?
Thank you,
Pavel
On Tue, Jul 31, 2018 at 8:45 AM wrote:
>
> From: Oscar Salvador
>
> __pagininit macro is being used to mark functions for:
>
> a) Functions that we do not need to keep once
Commit-ID: bd9f943e5d2a42d864f9692477a25034c9d47dcc
Gitweb: https://git.kernel.org/tip/bd9f943e5d2a42d864f9692477a25034c9d47dcc
Author: Pavel Tatashin
AuthorDate: Mon, 30 Jul 2018 09:52:52 -0400
Committer: Thomas Gleixner
CommitDate: Mon, 30 Jul 2018 19:33:35 +0200
sched/clock
Commit-ID: bd9f943e5d2a42d864f9692477a25034c9d47dcc
Gitweb: https://git.kernel.org/tip/bd9f943e5d2a42d864f9692477a25034c9d47dcc
Author: Pavel Tatashin
AuthorDate: Mon, 30 Jul 2018 09:52:52 -0400
Committer: Thomas Gleixner
CommitDate: Mon, 30 Jul 2018 19:33:35 +0200
sched/clock
Commit-ID: 684ad537abff987886d63fb3c573eeca40d7f2db
Gitweb: https://git.kernel.org/tip/684ad537abff987886d63fb3c573eeca40d7f2db
Author: Pavel Tatashin
AuthorDate: Wed, 25 Jul 2018 16:00:18 -0400
Committer: Thomas Gleixner
CommitDate: Mon, 30 Jul 2018 19:32:29 +0200
timekeeping
Commit-ID: 684ad537abff987886d63fb3c573eeca40d7f2db
Gitweb: https://git.kernel.org/tip/684ad537abff987886d63fb3c573eeca40d7f2db
Author: Pavel Tatashin
AuthorDate: Wed, 25 Jul 2018 16:00:18 -0400
Committer: Thomas Gleixner
CommitDate: Mon, 30 Jul 2018 19:32:29 +0200
timekeeping
>
> So i guess we agree that the right fix for this is to not touch struct
> pages when removing memory, correct?
Yes in my opinion that would be the correct fix.
Thank you,
Pavel
>
> --
>
> Thanks,
>
> David / dhildenb
>
>
> So i guess we agree that the right fix for this is to not touch struct
> pages when removing memory, correct?
Yes in my opinion that would be the correct fix.
Thank you,
Pavel
>
> --
>
> Thanks,
>
> David / dhildenb
>
On Mon, Jul 30, 2018 at 3:55 AM Dou Liyang wrote:
>
> kvm_get_preset_lpj() just be called at kvmclock_init(), So mark it
> __init as well.
Reviewed-by: Pavel Tatashin
Thank you,
Pavel
On Mon, Jul 30, 2018 at 3:55 AM Dou Liyang wrote:
>
> kvm_get_preset_lpj() just be called at kvmclock_init(), So mark it
> __init as well.
Reviewed-by: Pavel Tatashin
Thank you,
Pavel
only being
> used by is_dev_zone().
>
> This patch removes zone_id() and makes is_dev_zone() use zone_idx()
> to check the zone, so we do not have two things with the same
> functionality around.
>
> Signed-off-by: Oscar Salvador
Thank you:
Reviewed-by: Pavel Tatashin
only being
> used by is_dev_zone().
>
> This patch removes zone_id() and makes is_dev_zone() use zone_idx()
> to check the zone, so we do not have two things with the same
> functionality around.
>
> Signed-off-by: Oscar Salvador
Thank you:
Reviewed-by: Pavel Tatashin
ion, only call it once.
> Also fix comments:
> -s/authorative/authoritative
> -s/cyc2ns_init/tsc_init
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: Peter Zijlstra
> Cc: Pavel Tatashin
> Signed-off-by: Dou Liyang
Hi Dou,
ion, only call it once.
> Also fix comments:
> -s/authorative/authoritative
> -s/cyc2ns_init/tsc_init
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: Peter Zijlstra
> Cc: Pavel Tatashin
> Signed-off-by: Dou Liyang
Hi Dou,
-[ end trace 08080eb81afa002c ]---
Disable IRQs for the duration of generic_sched_clock_init().
Fixes: 857baa87b642 ("sched/clock: Enable sched clock early")
Signed-off-by: Pavel Tatashin
Reported-by: Guenter Roeck
---
kernel/sched/clock.c | 2 ++
1 file changed, 2 insertions(+)
dif
-[ end trace 08080eb81afa002c ]---
Disable IRQs for the duration of generic_sched_clock_init().
Fixes: 857baa87b642 ("sched/clock: Enable sched clock early")
Signed-off-by: Pavel Tatashin
Reported-by: Guenter Roeck
---
kernel/sched/clock.c | 2 ++
1 file changed, 2 insertions(+)
dif
> > - if (cd.actual_read_sched_clock == jiffy_sched_clock_read)
> > + if (cd.actual_read_sched_clock == jiffy_sched_clock_read) {
> > + local_irq_disable();
> > sched_clock_register(jiffy_sched_clock_read, BITS_PER_LONG,
> > HZ);
> > +
> > - if (cd.actual_read_sched_clock == jiffy_sched_clock_read)
> > + if (cd.actual_read_sched_clock == jiffy_sched_clock_read) {
> > + local_irq_disable();
> > sched_clock_register(jiffy_sched_clock_read, BITS_PER_LONG,
> > HZ);
> > +
On Mon, Jul 30, 2018 at 8:11 AM David Hildenbrand wrote:
>
> On 30.07.2018 14:05, Michal Hocko wrote:
> > On Mon 30-07-18 13:53:06, David Hildenbrand wrote:
> >> On 30.07.2018 13:30, Michal Hocko wrote:
> >>> On Fri 27-07-18 18:54:54, David Hildenbrand wrote:
> Right now, struct pages are
501 - 600 of 2213 matches
Mail list logo
