On Mon, Jul 16, 2018 at 03:03:31PM -0400, Rik van Riel wrote:
> The mm_struct always contains a cpumask bitmap, regardless of
> CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
> simplify things, and simply have one bitmask at the end of the
> mm_struct for the mm_cpumask.
>
> This
On Mon, Jul 16, 2018 at 03:03:31PM -0400, Rik van Riel wrote:
> The mm_struct always contains a cpumask bitmap, regardless of
> CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
> simplify things, and simply have one bitmask at the end of the
> mm_struct for the mm_cpumask.
>
> This
The mm_struct always contains a cpumask bitmap, regardless of
CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
simplify things, and simply have one bitmask at the end of the
mm_struct for the mm_cpumask.
This does necessitate moving everything else in mm_struct into
an anonymous
The mm_struct always contains a cpumask bitmap, regardless of
CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
simplify things, and simply have one bitmask at the end of the
mm_struct for the mm_cpumask.
This does necessitate moving everything else in mm_struct into
an anonymous
* Rik van Riel wrote:
> On Mon, 2018-07-16 at 00:59 +0200, Ingo Molnar wrote:
> > * Rik van Riel wrote:
> >
> > > The mm_struct always contains a cpumask bitmap, regardless of
> > > CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
> > > simplify things, and simply have one
* Rik van Riel wrote:
> On Mon, 2018-07-16 at 00:59 +0200, Ingo Molnar wrote:
> > * Rik van Riel wrote:
> >
> > > The mm_struct always contains a cpumask bitmap, regardless of
> > > CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
> > > simplify things, and simply have one
On Mon, 2018-07-16 at 00:59 +0200, Ingo Molnar wrote:
> * Rik van Riel wrote:
>
> > The mm_struct always contains a cpumask bitmap, regardless of
> > CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
> > simplify things, and simply have one bitmask at the end of the
> > mm_struct for
On Mon, 2018-07-16 at 00:59 +0200, Ingo Molnar wrote:
> * Rik van Riel wrote:
>
> > The mm_struct always contains a cpumask bitmap, regardless of
> > CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
> > simplify things, and simply have one bitmask at the end of the
> > mm_struct for
* Rik van Riel wrote:
> The mm_struct always contains a cpumask bitmap, regardless of
> CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
> simplify things, and simply have one bitmask at the end of the
> mm_struct for the mm_cpumask.
>
> This does necessitate moving everything
* Rik van Riel wrote:
> The mm_struct always contains a cpumask bitmap, regardless of
> CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
> simplify things, and simply have one bitmask at the end of the
> mm_struct for the mm_cpumask.
>
> This does necessitate moving everything
The mm_struct always contains a cpumask bitmap, regardless of
CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
simplify things, and simply have one bitmask at the end of the
mm_struct for the mm_cpumask.
This does necessitate moving everything else in mm_struct into
an anonymous
The mm_struct always contains a cpumask bitmap, regardless of
CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
simplify things, and simply have one bitmask at the end of the
mm_struct for the mm_cpumask.
This does necessitate moving everything else in mm_struct into
an anonymous
On Mon, 2018-07-09 at 17:38 -0400, Rik van Riel wrote:
>
> I added your code, and Signed-off-By in patch
> 1 for version 5 of the series.
No objection, but no need (like taking credit for fixing a typo:).
On Mon, 2018-07-09 at 17:38 -0400, Rik van Riel wrote:
>
> I added your code, and Signed-off-By in patch
> 1 for version 5 of the series.
No objection, but no need (like taking credit for fixing a typo:).
On Sun, 2018-07-08 at 16:13 +0200, Mike Galbraith wrote:
> On Sat, 2018-07-07 at 17:25 -0400, Rik van Riel wrote:
> >
> > > ./include/linux/bitmap.h:208:3: warning: ‘memset’ writing 64
> > > bytes
> > > into a region of size 0 overflows the destination [-Wstringop-
> > > overflow=]
> > >
On Sun, 2018-07-08 at 16:13 +0200, Mike Galbraith wrote:
> On Sat, 2018-07-07 at 17:25 -0400, Rik van Riel wrote:
> >
> > > ./include/linux/bitmap.h:208:3: warning: ‘memset’ writing 64
> > > bytes
> > > into a region of size 0 overflows the destination [-Wstringop-
> > > overflow=]
> > >
BTW, a second gripe ala the first, but wrt mm_init_cpumask(_mm):
In function ‘bitmap_zero’,
inlined from ‘cpumask_clear’ at ./include/linux/cpumask.h:378:2,
inlined from ‘mm_init_cpumask’ at ./include/linux/mm_types.h:504:2,
inlined from ‘efi_alloc_page_tables’ at
BTW, a second gripe ala the first, but wrt mm_init_cpumask(_mm):
In function ‘bitmap_zero’,
inlined from ‘cpumask_clear’ at ./include/linux/cpumask.h:378:2,
inlined from ‘mm_init_cpumask’ at ./include/linux/mm_types.h:504:2,
inlined from ‘efi_alloc_page_tables’ at
On Sat, 2018-07-07 at 17:25 -0400, Rik van Riel wrote:
>
> > ./include/linux/bitmap.h:208:3: warning: ‘memset’ writing 64 bytes
> > into a region of size 0 overflows the destination [-Wstringop-
> > overflow=]
> >memset(dst, 0, len);
> >^~~
>
> I don't understand this
On Sat, 2018-07-07 at 17:25 -0400, Rik van Riel wrote:
>
> > ./include/linux/bitmap.h:208:3: warning: ‘memset’ writing 64 bytes
> > into a region of size 0 overflows the destination [-Wstringop-
> > overflow=]
> >memset(dst, 0, len);
> >^~~
>
> I don't understand this
I. On Sat, 2018-07-07 at 10:23 +0200, Mike Galbraith wrote:
> On Fri, 2018-07-06 at 17:56 -0400, Rik van Riel wrote:
> > The mm_struct always contains a cpumask bitmap, regardless of
> > CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
> > simplify things, and simply have one
I. On Sat, 2018-07-07 at 10:23 +0200, Mike Galbraith wrote:
> On Fri, 2018-07-06 at 17:56 -0400, Rik van Riel wrote:
> > The mm_struct always contains a cpumask bitmap, regardless of
> > CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
> > simplify things, and simply have one
On Fri, 2018-07-06 at 17:56 -0400, Rik van Riel wrote:
> The mm_struct always contains a cpumask bitmap, regardless of
> CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
> simplify things, and simply have one bitmask at the end of the
> mm_struct for the mm_cpumask.
Otherwise virgin
On Fri, 2018-07-06 at 17:56 -0400, Rik van Riel wrote:
> The mm_struct always contains a cpumask bitmap, regardless of
> CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
> simplify things, and simply have one bitmask at the end of the
> mm_struct for the mm_cpumask.
Otherwise virgin
The mm_struct always contains a cpumask bitmap, regardless of
CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
simplify things, and simply have one bitmask at the end of the
mm_struct for the mm_cpumask.
This does necessitate moving everything else in mm_struct into
an anonymous
The mm_struct always contains a cpumask bitmap, regardless of
CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
simplify things, and simply have one bitmask at the end of the
mm_struct for the mm_cpumask.
This does necessitate moving everything else in mm_struct into
an anonymous
Hi Rik,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.18-rc2 next-20180629]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi Rik,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.18-rc2 next-20180629]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
The mm_struct always contains a cpumask bitmap, regardless of
CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
simplify things, and simply have one bitmask at the end of the
mm_struct for the mm_cpumask.
This does necessitate moving everything else in mm_struct into
an anonymous
The mm_struct always contains a cpumask bitmap, regardless of
CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
simplify things, and simply have one bitmask at the end of the
mm_struct for the mm_cpumask.
This does necessitate moving everything else in mm_struct into
an anonymous
On Fri, 2018-06-22 at 08:10 -0700, Dave Hansen wrote:
> On 06/20/2018 12:56 PM, Rik van Riel wrote:
> > /*
> > -* FIXME! The "sizeof(struct mm_struct)" currently
> > includes the
> > -* whole struct cpumask for the OFFSTACK case. We could
> > change
> > -* this to *only* allocate
On Fri, 2018-06-22 at 08:10 -0700, Dave Hansen wrote:
> On 06/20/2018 12:56 PM, Rik van Riel wrote:
> > /*
> > -* FIXME! The "sizeof(struct mm_struct)" currently
> > includes the
> > -* whole struct cpumask for the OFFSTACK case. We could
> > change
> > -* this to *only* allocate
On 06/20/2018 12:56 PM, Rik van Riel wrote:
> /*
> - * FIXME! The "sizeof(struct mm_struct)" currently includes the
> - * whole struct cpumask for the OFFSTACK case. We could change
> - * this to *only* allocate as much of it as required by the
> - * maximum number of
On 06/20/2018 12:56 PM, Rik van Riel wrote:
> /*
> - * FIXME! The "sizeof(struct mm_struct)" currently includes the
> - * whole struct cpumask for the OFFSTACK case. We could change
> - * this to *only* allocate as much of it as required by the
> - * maximum number of
On Thu, 2018-06-21 at 05:32 +0800, kbuild test robot wrote:
> Hi Rik,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on v4.17]
> [also build test ERROR on next-20180620]
> [cannot apply to tip/x86/core linus/master mmotm/master v4.18-rc1]
> [if your patch is
On Thu, 2018-06-21 at 05:32 +0800, kbuild test robot wrote:
> Hi Rik,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on v4.17]
> [also build test ERROR on next-20180620]
> [cannot apply to tip/x86/core linus/master mmotm/master v4.18-rc1]
> [if your patch is
Hi Rik,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on v4.17]
[also build test WARNING on next-20180620]
[cannot apply to tip/x86/core linus/master mmotm/master v4.18-rc1]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve
Hi Rik,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on v4.17]
[also build test WARNING on next-20180620]
[cannot apply to tip/x86/core linus/master mmotm/master v4.18-rc1]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve
Hi Rik,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v4.17]
[also build test ERROR on next-20180620]
[cannot apply to tip/x86/core linus/master mmotm/master v4.18-rc1]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the
Hi Rik,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v4.17]
[also build test ERROR on next-20180620]
[cannot apply to tip/x86/core linus/master mmotm/master v4.18-rc1]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the
The mm_struct always contains a cpumask bitmap, regardless of
CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
simplify things, and simply have one bitmask at the end of the
mm_struct for the mm_cpumask.
The second step is to determine the correct size for the
mm_struct slab object
The mm_struct always contains a cpumask bitmap, regardless of
CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
simplify things, and simply have one bitmask at the end of the
mm_struct for the mm_cpumask.
The second step is to determine the correct size for the
mm_struct slab object
42 matches
Mail list logo
