On Tue, 10 Jul 2018, Yang, Bin wrote:
> > +* FIXME:
> > +* 1) Make this yell loudly if something tries to set a full
> > +*large page to something which is not allowed.
>
> I am trying to work out a patch based on your sample code and
> comments.
> I do not understand here why it
On Wed, 2018-07-04 at 16:01 +0200, Thomas Gleixner wrote:
> On Wed, 4 Jul 2018, Yang, Bin wrote:
> > e820 table:
> > =
> >
> > [0.00] BIOS-e820: [mem 0x-
> > 0x0009fbff]
> > usable
> > [0.00] BIOS-e820: [mem 0x0009fc00-
> > 0x
On Thu, 5 Jul 2018, Yang, Bin wrote:
> Sorry for the misunderstanding. I mean I will improve the check loop in patch
> v2.
> I just submitted patch v2. Thanks in advance for your kind review.
Did you actually read what I wrote?
> On Thu, 5 Jul 2018, Yang, Bin wrote:
>
> Please do not top post
Sorry for the misunderstanding. I mean I will improve the check loop in patch
v2.
I just submitted patch v2. Thanks in advance for your kind review.
Thanks,
Bin
On 05/07/2018, 1:30 PM, "Thomas Gleixner" wrote:
Sorry, I don't see in which way your patch would improve the check loop.
On Thu, 5 Jul 2018, Yang, Bin wrote:
Please do not top post.
> This is what my new patch tries to improve.
> On 04/07/2018, 10:02 PM, "Thomas Gleixner" wrote:
>
> The check loop itself is stupid as well. Instead of looping in 4K steps
> the thing can be rewritten to check for overl
This is what my new patch tries to improve.
On 04/07/2018, 10:02 PM, "Thomas Gleixner" wrote:
The check loop itself is stupid as well. Instead of looping in 4K steps
the thing can be rewritten to check for overlapping ranges and then check
explicitely for those. If there is no
On Wed, 4 Jul 2018, Yang, Bin wrote:
> e820 table:
> =
>
> [0.00] BIOS-e820: [mem 0x-0x0009fbff]
> usable
> [0.00] BIOS-e820: [mem 0x0009fc00-0x0009]
> reserved
> [0.00] BIOS-e820: [mem 0x000f-0x000
e820 table:
=
[0.00] BIOS-e820: [mem 0x-0x0009fbff]
usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009]
reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f]
reserved
[0.00] BIOS-e820: [mem 0x
On Wed, 4 Jul 2018, Yang, Bin wrote:
> You are completely right. After considering, I think my patch is like a
> workaround but not real fix. I am trying to re-write a new patch
> without cache implementation.
Care to explain the actual problem coherently _before_ writing yet another
patch?
Than
You are completely right. After considering, I think my patch is like a
workaround but not real fix. I am trying to re-write a new patch
without cache implementation.
Please give me one or two days to re-write this patch and discribe it
more clearly in commit comment.
thanks,
Bin
On Wed, 2018-0
On Wed, 4 Jul 2018, Yang, Bin wrote:
> thanks for reviewing my patch. I will update a new patch version based
> on your feedback soon
Take your time.
> On Tue, 2018-07-03 at 15:57 +0200, Thomas Gleixner wrote:
> Below is the new commit comment I will use in new patch version soon
> > Please do n
thanks for reviewing my patch. I will update a new patch version based
on your feedback soon
On Tue, 2018-07-03 at 15:57 +0200, Thomas Gleixner wrote:
> Bin,
>
> On Thu, 28 Jun 2018, Bin Yang wrote:
>
> thanks for submitting this.
>
> > This issue can be easily triggered by free_initmem() f
Bin,
On Thu, 28 Jun 2018, Bin Yang wrote:
thanks for submitting this.
> This issue can be easily triggered by free_initmem() functuion on
> x86_64 cpu.
Please do not use the output of git show for submitting a patch. Use git
format-patch(1).
> If cpu supports "pdpe1gb", kernel will
This issue can be easily triggered by free_initmem() functuion on
x86_64 cpu.
When changing page attr, __change_page_attr_set_clr will call
__change_page_attr for every 4K page. And try_preserve_large_page
will be called to check whether it needs to split the large page.
I
14 matches
Mail list logo
