On Sun, Mar 24, 2019 at 03:29:04PM +0100, Thomas Gleixner wrote:
>Find a mostly untested patch which implements this below. I just booted it
>in a 64bit guest and it did not explode.
>
>It removes 55 lines of code instead of adding 35 and reduces the binary
>size by 408 bytes on 64bit and 128
On Thu, Mar 28, 2019 at 09:08:43AM +0100, Thomas Gleixner wrote:
>On Thu, 28 Mar 2019, Wei Yang wrote:
>> On Sun, Mar 24, 2019 at 03:29:04PM +0100, Thomas Gleixner wrote:
>> My question is to the for loop.
>>
>> For example, we have a range
>>
>>+--+-+---+
>>
On Thu, 28 Mar 2019, Wei Yang wrote:
> On Sun, Mar 24, 2019 at 03:29:04PM +0100, Thomas Gleixner wrote:
> My question is to the for loop.
>
> For example, we have a range
>
>+--+-+---+
>^ 128M 1G 2G
>128M - 4K
>
> If my
Wei,
On Thu, 28 Mar 2019, Wei Yang wrote:
please trim your replies. It's annoying if one has to search the content in
the middle of a large useless quote.
> On Sun, Mar 24, 2019 at 03:29:04PM +0100, Thomas Gleixner wrote:
> >Wei,
> >-static int __meminit split_mem_range(struct map_range *mr,
On Sun, Mar 24, 2019 at 03:29:04PM +0100, Thomas Gleixner wrote:
>
>+static int __meminit split_mem_range(struct map_range *mr, unsigned long
>start,
>+ unsigned long end)
>+{
>+ static const struct mapinfo mapinfos[] = {
> #ifdef CONFIG_X86_64
>+
On Sun, Mar 24, 2019 at 03:29:04PM +0100, Thomas Gleixner wrote:
>Wei,
>
>On Tue, 12 Feb 2019, Wei Yang wrote:
>>
>> This patch changes the implementation from the first perception to the
>> second to reduce one different handling on end_pfn. After doing so, the
>> code is easier to read.
>
>It's
On Thu, Mar 28, 2019 at 01:16:08AM +0100, Thomas Gleixner wrote:
>Wei,
>
>On Wed, 27 Mar 2019, Wei Yang wrote:
>> On Sun, Mar 24, 2019 at 03:29:04PM +0100, Thomas Gleixner wrote:
>> >Note, it's a combo of changes (including your patch 1/6) and needs to be
>> >split up. It would be nice if you have
Wei,
On Wed, 27 Mar 2019, Wei Yang wrote:
> On Sun, Mar 24, 2019 at 03:29:04PM +0100, Thomas Gleixner wrote:
> >Note, it's a combo of changes (including your patch 1/6) and needs to be
> >split up. It would be nice if you have time to split it up into separate
> >patches, add proper changelogs
On Sun, Mar 24, 2019 at 03:29:04PM +0100, Thomas Gleixner wrote:
>Wei,
>
>On Tue, 12 Feb 2019, Wei Yang wrote:
>>
>> This patch changes the implementation from the first perception to the
>> second to reduce one different handling on end_pfn. After doing so, the
>> code is easier to read.
>
>It's
Wei,
On Tue, 12 Feb 2019, Wei Yang wrote:
>
> This patch changes the implementation from the first perception to the
> second to reduce one different handling on end_pfn. After doing so, the
> code is easier to read.
It's maybe slightly easier to read, but it's still completely unreadable
As the comment explains, there are at most 5 possible ranges:
kkkmmmGGGmmmkkk
(A)(B)(C)(D)(E)
While there are two ways to perceive:
* C & D are extra ranges on X86_64
* B & C are extra ranges on X86_64
Current implementation takes the first way, which leads
11 matches
Mail list logo
