On Thu, 2018-12-20 at 08:35 +, Chris Wilson wrote:
> Quoting Bin Yang (2018-12-20 08:01:35)
> > Normally, i915_request_alloc() and i915_request_add() will be called
> > in sequence with drm.struct_mutex locked. But in
> > intel_vgpu_create_workload(), it will pre-allocate the request and
> >
On Wed, 2018-09-12 at 10:44 -0700, Kees Cook wrote:
> On Tue, Sep 11, 2018 at 8:36 PM, Bin Yang wrote:
> > persistent_ram_vmap() returns the page start vaddr.
> > persistent_ram_iomap() supports non-page-aligned mapping.
>
> Oh, yes, good catch. This should probably be explicitly mentioned in
>
On Wed, 2018-09-12 at 10:44 -0700, Kees Cook wrote:
> On Tue, Sep 11, 2018 at 8:36 PM, Bin Yang wrote:
> > persistent_ram_vmap() returns the page start vaddr.
> > persistent_ram_iomap() supports non-page-aligned mapping.
>
> Oh, yes, good catch. This should probably be explicitly mentioned in
>
On Fri, 2018-09-07 at 17:01 +0200, Thomas Gleixner wrote:
> Avoid the extra variable and gotos by splitting the function into the
> actual algorithm and a callable function which contains the lock
> protection.
>
> Rename it to should_split_large_page() while at it so the return values make
>
On Fri, 2018-09-07 at 17:01 +0200, Thomas Gleixner wrote:
> Avoid the extra variable and gotos by splitting the function into the
> actual algorithm and a callable function which contains the lock
> protection.
>
> Rename it to should_split_large_page() while at it so the return values make
>
On Fri, 2018-09-07 at 10:21 +0200, Thomas Gleixner wrote:
> On Fri, 7 Sep 2018, Yang, Bin wrote:
> > On Fri, 2018-09-07 at 09:49 +0200, Thomas Gleixner wrote:
> > > On Fri, 7 Sep 2018, Yang, Bin wrote:
> > > > On Tue, 2018-09-04 at 14:22 +0200, Thomas Gleixner wrote:
On Fri, 2018-09-07 at 10:21 +0200, Thomas Gleixner wrote:
> On Fri, 7 Sep 2018, Yang, Bin wrote:
> > On Fri, 2018-09-07 at 09:49 +0200, Thomas Gleixner wrote:
> > > On Fri, 7 Sep 2018, Yang, Bin wrote:
> > > > On Tue, 2018-09-04 at 14:22 +0200, Thomas Gleixner wrote:
On Fri, 2018-09-07 at 09:49 +0200, Thomas Gleixner wrote:
> On Fri, 7 Sep 2018, Yang, Bin wrote:
> > On Tue, 2018-09-04 at 14:22 +0200, Thomas Gleixner wrote:
> >
> > I just write a test.c to compare the result between overlap() and
> > original within().
>
> You
On Fri, 2018-09-07 at 09:49 +0200, Thomas Gleixner wrote:
> On Fri, 7 Sep 2018, Yang, Bin wrote:
> > On Tue, 2018-09-04 at 14:22 +0200, Thomas Gleixner wrote:
> >
> > I just write a test.c to compare the result between overlap() and
> > original within().
>
> You
On Tue, 2018-09-04 at 18:52 +0200, Thomas Gleixner wrote:
> On Tue, 4 Sep 2018, Thomas Gleixner wrote:
> > On Tue, 4 Sep 2018, Yang, Bin wrote:
> > > On Tue, 2018-09-04 at 00:27 +0200, Thomas Gleixner wrote:
> > > > On Tue, 21 Aug 2018, Bin Yang wro
On Tue, 2018-09-04 at 18:52 +0200, Thomas Gleixner wrote:
> On Tue, 4 Sep 2018, Thomas Gleixner wrote:
> > On Tue, 4 Sep 2018, Yang, Bin wrote:
> > > On Tue, 2018-09-04 at 00:27 +0200, Thomas Gleixner wrote:
> > > > On Tue, 21 Aug 2018, Bin Yang wro
On Tue, 2018-09-04 at 14:22 +0200, Thomas Gleixner wrote:
> On Tue, 21 Aug 2018, Bin Yang wrote:
> >
> > +static inline bool
> > +overlap(unsigned long start1, unsigned long end1,
> > + unsigned long start2, unsigned long end2)
> > +{
> > + /* Is 'start2' within area 1? */
> > + if
On Tue, 2018-09-04 at 14:22 +0200, Thomas Gleixner wrote:
> On Tue, 21 Aug 2018, Bin Yang wrote:
> >
> > +static inline bool
> > +overlap(unsigned long start1, unsigned long end1,
> > + unsigned long start2, unsigned long end2)
> > +{
> > + /* Is 'start2' within area 1? */
> > + if
On Tue, 2018-09-04 at 17:11 +0800, Bin Yang wrote:
> On Tue, 2018-09-04 at 09:49 +0200, Thomas Gleixner wrote:
> > On Tue, 4 Sep 2018, Yang, Bin wrote:
> > > On Mon, 2018-09-03 at 23:57 +0200, Thomas Gleixner wrote:
> > > >
> > > > The last patch whic
On Tue, 2018-09-04 at 17:11 +0800, Bin Yang wrote:
> On Tue, 2018-09-04 at 09:49 +0200, Thomas Gleixner wrote:
> > On Tue, 4 Sep 2018, Yang, Bin wrote:
> > > On Mon, 2018-09-03 at 23:57 +0200, Thomas Gleixner wrote:
> > > >
> > > > The last patch whic
On Tue, 2018-09-04 at 09:49 +0200, Thomas Gleixner wrote:
> On Tue, 4 Sep 2018, Yang, Bin wrote:
> > On Mon, 2018-09-03 at 23:57 +0200, Thomas Gleixner wrote:
> > >
> > > The last patch which does the overlap check is equally broken:
> >
> > Sorry that
On Tue, 2018-09-04 at 09:49 +0200, Thomas Gleixner wrote:
> On Tue, 4 Sep 2018, Yang, Bin wrote:
> > On Mon, 2018-09-03 at 23:57 +0200, Thomas Gleixner wrote:
> > >
> > > The last patch which does the overlap check is equally broken:
> >
> > Sorry that
On Mon, 2018-09-03 at 23:57 +0200, Thomas Gleixner wrote:
> On Tue, 21 Aug 2018, Bin Yang wrote:
> > --- a/arch/x86/mm/pageattr.c
> > +++ b/arch/x86/mm/pageattr.c
> > @@ -629,6 +629,22 @@ try_preserve_large_page(pte_t *kpte, unsigned long
> > address,
> > new_prot =
On Mon, 2018-09-03 at 23:57 +0200, Thomas Gleixner wrote:
> On Tue, 21 Aug 2018, Bin Yang wrote:
> > --- a/arch/x86/mm/pageattr.c
> > +++ b/arch/x86/mm/pageattr.c
> > @@ -629,6 +629,22 @@ try_preserve_large_page(pte_t *kpte, unsigned long
> > address,
> > new_prot =
On Tue, 2018-09-04 at 00:27 +0200, Thomas Gleixner wrote:
> On Tue, 21 Aug 2018, Bin Yang wrote:
> > @@ -625,6 +625,7 @@ try_preserve_large_page(pte_t *kpte, unsigned long
> > address,
> >
> > psize = page_level_size(level);
> > pmask = page_level_mask(level);
> > + addr = address &
On Tue, 2018-09-04 at 00:27 +0200, Thomas Gleixner wrote:
> On Tue, 21 Aug 2018, Bin Yang wrote:
> > @@ -625,6 +625,7 @@ try_preserve_large_page(pte_t *kpte, unsigned long
> > address,
> >
> > psize = page_level_size(level);
> > pmask = page_level_mask(level);
> > + addr = address &
On Tue, 2018-09-04 at 00:10 +0200, Thomas Gleixner wrote:
> On Tue, 21 Aug 2018, Bin Yang wrote:
> > /*
> > + * static_protections() "forces" page protections for some address
> > + * ranges. Return true if any part of the address/len range is forced
> > + * to change from 'prot'.
> > + */
> >
On Tue, 2018-09-04 at 00:10 +0200, Thomas Gleixner wrote:
> On Tue, 21 Aug 2018, Bin Yang wrote:
> > /*
> > + * static_protections() "forces" page protections for some address
> > + * ranges. Return true if any part of the address/len range is forced
> > + * to change from 'prot'.
> > + */
> >
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
> > [
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
> > [
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.
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.
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
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
level=3; and the check loop count is 262144, exit loop after 861 usecs
on my board
the actual problem
===
sometimes, free_init_pages returns after hundreds of secounds. The
major impact is kernel boot time.
On Wed, 2018-07-04 at 11:20 +0200, Thomas Gleixner wrote:
> On Wed, 4 J
level=3; and the check loop count is 262144, exit loop after 861 usecs
on my board
the actual problem
===
sometimes, free_init_pages returns after hundreds of secounds. The
major impact is kernel boot time.
On Wed, 2018-07-04 at 11:20 +0200, Thomas Gleixner wrote:
> On Wed, 4 J
-07-04 at 09:40 +0200, Thomas Gleixner wrote:
> 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
-07-04 at 09:40 +0200, Thomas Gleixner wrote:
> 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
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()
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()
35 matches
Mail list logo
