2016-02-15 19:06 GMT+09:00 Xishi Qiu :
> On 2016/2/15 10:42, Joonsoo Kim wrote:
>
>>>
>>> I have a question about the zone continuity. because hole exists at
>>> arbitrary position in a page block. Therefore, only pageblock_pf_to_page()
>>> is insufficiency, whether pageblock
2016-02-15 19:06 GMT+09:00 Xishi Qiu :
> On 2016/2/15 10:42, Joonsoo Kim wrote:
>
>>>
>>> I have a question about the zone continuity. because hole exists at
>>> arbitrary position in a page block. Therefore, only pageblock_pf_to_page()
>>> is insufficiency, whether pageblock aligned pfn or not ,
On 2016/2/15 10:42, Joonsoo Kim wrote:
>>
>> I have a question about the zone continuity. because hole exists at
>> arbitrary position in a page block. Therefore, only pageblock_pf_to_page()
>> is insufficiency, whether pageblock aligned pfn or not , the
>> pfn_valid_within()
>> is necessary.
>>
On 2016/2/15 10:42, Joonsoo Kim wrote:
>>
>> I have a question about the zone continuity. because hole exists at
>> arbitrary position in a page block. Therefore, only pageblock_pf_to_page()
>> is insufficiency, whether pageblock aligned pfn or not , the
>> pfn_valid_within()
>> is necessary.
>>
On Sun, Feb 14, 2016 at 06:21:03PM +0800, zhong jiang wrote:
> On 2016/2/6 0:11, Joonsoo Kim wrote:
> > 2016-02-05 9:49 GMT+09:00 Andrew Morton :
> >> On Thu, 4 Feb 2016 15:19:35 +0900 Joonsoo Kim wrote:
> >>
> >>> There is a performance drop report
On Sun, Feb 14, 2016 at 06:21:03PM +0800, zhong jiang wrote:
> On 2016/2/6 0:11, Joonsoo Kim wrote:
> > 2016-02-05 9:49 GMT+09:00 Andrew Morton :
> >> On Thu, 4 Feb 2016 15:19:35 +0900 Joonsoo Kim wrote:
> >>
> >>> There is a performance drop report due to hugepage allocation and in there
> >>>
On 2016/2/6 0:11, Joonsoo Kim wrote:
> 2016-02-05 9:49 GMT+09:00 Andrew Morton :
>> On Thu, 4 Feb 2016 15:19:35 +0900 Joonsoo Kim wrote:
>>
>>> There is a performance drop report due to hugepage allocation and in there
>>> half of cpu time are spent on pageblock_pfn_to_page() in compaction [1].
On 2016/2/6 0:11, Joonsoo Kim wrote:
> 2016-02-05 9:49 GMT+09:00 Andrew Morton :
>> On Thu, 4 Feb 2016 15:19:35 +0900 Joonsoo Kim wrote:
>>
>>> There is a performance drop report due to hugepage allocation and in there
>>> half of cpu time are spent
2016-02-11 3:58 GMT+09:00 Andrew Morton :
> On Wed, 10 Feb 2016 14:42:57 +0100 Vlastimil Babka wrote:
>
>> > --- a/mm/memory_hotplug.c
>> > +++ b/mm/memory_hotplug.c
>> > @@ -509,6 +509,8 @@ int __ref __add_pages(int nid, struct zone *zone,
>> > unsigned long phys_start_pfn,
>> > int
On Wed, 10 Feb 2016 14:42:57 +0100 Vlastimil Babka wrote:
> > --- a/mm/memory_hotplug.c
> > +++ b/mm/memory_hotplug.c
> > @@ -509,6 +509,8 @@ int __ref __add_pages(int nid, struct zone *zone,
> > unsigned long phys_start_pfn,
> > int start_sec, end_sec;
> > struct vmem_altmap *altmap;
>
On 02/09/2016 09:53 PM, Andrew Morton wrote:
> On Tue, 9 Feb 2016 18:58:32 +0100 Vlastimil Babka wrote:
>
>> On 02/05/2016 05:11 PM, Joonsoo Kim wrote:
>>> Yeah, it seems wrong to me. :)
>>> Here goes fix.
>>
>> Doesn't apply for me, even after fixing the most obvious line wraps.
>> Seems like
On 02/09/2016 09:53 PM, Andrew Morton wrote:
> On Tue, 9 Feb 2016 18:58:32 +0100 Vlastimil Babka wrote:
>
>> On 02/05/2016 05:11 PM, Joonsoo Kim wrote:
>>> Yeah, it seems wrong to me. :)
>>> Here goes fix.
>>
>> Doesn't apply for me, even after fixing the most obvious line wraps.
On Wed, 10 Feb 2016 14:42:57 +0100 Vlastimil Babka wrote:
> > --- a/mm/memory_hotplug.c
> > +++ b/mm/memory_hotplug.c
> > @@ -509,6 +509,8 @@ int __ref __add_pages(int nid, struct zone *zone,
> > unsigned long phys_start_pfn,
> > int start_sec, end_sec;
> > struct
2016-02-11 3:58 GMT+09:00 Andrew Morton :
> On Wed, 10 Feb 2016 14:42:57 +0100 Vlastimil Babka wrote:
>
>> > --- a/mm/memory_hotplug.c
>> > +++ b/mm/memory_hotplug.c
>> > @@ -509,6 +509,8 @@ int __ref __add_pages(int nid, struct zone *zone,
>> >
On Tue, 9 Feb 2016 18:58:32 +0100 Vlastimil Babka wrote:
> On 02/05/2016 05:11 PM, Joonsoo Kim wrote:
> > Yeah, it seems wrong to me. :)
> > Here goes fix.
>
> Doesn't apply for me, even after fixing the most obvious line wraps.
> Seems like the version in mmotm is still your original patch and
On 02/05/2016 05:11 PM, Joonsoo Kim wrote:
> Yeah, it seems wrong to me. :)
> Here goes fix.
Doesn't apply for me, even after fixing the most obvious line wraps.
Seems like the version in mmotm is still your original patch and
Andrew's hotfix?
On Tue, 9 Feb 2016 18:58:32 +0100 Vlastimil Babka wrote:
> On 02/05/2016 05:11 PM, Joonsoo Kim wrote:
> > Yeah, it seems wrong to me. :)
> > Here goes fix.
>
> Doesn't apply for me, even after fixing the most obvious line wraps.
> Seems like the version in mmotm is still your
On 02/05/2016 05:11 PM, Joonsoo Kim wrote:
> Yeah, it seems wrong to me. :)
> Here goes fix.
Doesn't apply for me, even after fixing the most obvious line wraps.
Seems like the version in mmotm is still your original patch and
Andrew's hotfix?
2016-02-05 9:49 GMT+09:00 Andrew Morton :
> On Thu, 4 Feb 2016 15:19:35 +0900 Joonsoo Kim wrote:
>
>> There is a performance drop report due to hugepage allocation and in there
>> half of cpu time are spent on pageblock_pfn_to_page() in compaction [1].
>> In that workload, compaction is
2016-02-05 9:49 GMT+09:00 Andrew Morton :
> On Thu, 4 Feb 2016 15:19:35 +0900 Joonsoo Kim wrote:
>
>> There is a performance drop report due to hugepage allocation and in there
>> half of cpu time are spent on pageblock_pfn_to_page() in compaction
On Thu, 4 Feb 2016 15:19:35 +0900 Joonsoo Kim wrote:
> There is a performance drop report due to hugepage allocation and in there
> half of cpu time are spent on pageblock_pfn_to_page() in compaction [1].
> In that workload, compaction is triggered to make hugepage but most of
> pageblocks are
On Thu, 4 Feb 2016 15:19:35 +0900 Joonsoo Kim wrote:
> There is a performance drop report due to hugepage allocation and in there
> half of cpu time are spent on pageblock_pfn_to_page() in compaction [1].
> In that workload, compaction is triggered to make hugepage but most of
There is a performance drop report due to hugepage allocation and in there
half of cpu time are spent on pageblock_pfn_to_page() in compaction [1].
In that workload, compaction is triggered to make hugepage but most of
pageblocks are un-available for compaction due to pageblock type and
skip bit
There is a performance drop report due to hugepage allocation and in there
half of cpu time are spent on pageblock_pfn_to_page() in compaction [1].
In that workload, compaction is triggered to make hugepage but most of
pageblocks are un-available for compaction due to pageblock type and
skip bit
24 matches
Mail list logo