On Tue, 8 Sep 2015, Russell King - ARM Linux wrote:
> On Mon, Sep 07, 2015 at 10:01:41PM -0400, Nicolas Pitre wrote:
>
[...]
> > This is passed to iotable_init(), then to create_mapping(). There you
> > have:
> >
> > if ((md->type == MT_DEVICE || md->type == MT_ROM) &&
> >
On Mon, Sep 07, 2015 at 10:01:41PM -0400, Nicolas Pitre wrote:
> On Tue, 8 Sep 2015, Russell King - ARM Linux wrote:
>
> > On Mon, Sep 07, 2015 at 03:40:36PM -0400, Nicolas Pitre wrote:
> > > On Mon, 7 Sep 2015, Arnd Bergmann wrote:
> > >
> > > > On Thursday 03 September 2015 21:24:00 Nicolas
On Mon, Sep 07, 2015 at 10:01:41PM -0400, Nicolas Pitre wrote:
> On Tue, 8 Sep 2015, Russell King - ARM Linux wrote:
>
> > On Mon, Sep 07, 2015 at 03:40:36PM -0400, Nicolas Pitre wrote:
> > > On Mon, 7 Sep 2015, Arnd Bergmann wrote:
> > >
> > > > On Thursday 03 September 2015 21:24:00 Nicolas
On Tue, 8 Sep 2015, Russell King - ARM Linux wrote:
> On Mon, Sep 07, 2015 at 10:01:41PM -0400, Nicolas Pitre wrote:
>
[...]
> > This is passed to iotable_init(), then to create_mapping(). There you
> > have:
> >
> > if ((md->type == MT_DEVICE || md->type == MT_ROM) &&
> >
On Tue, 8 Sep 2015, Russell King - ARM Linux wrote:
> On Mon, Sep 07, 2015 at 03:40:36PM -0400, Nicolas Pitre wrote:
> > On Mon, 7 Sep 2015, Arnd Bergmann wrote:
> >
> > > On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote:
> > > > If 768MB targets were common place then it could be
On Mon, Sep 07, 2015 at 03:40:36PM -0400, Nicolas Pitre wrote:
> On Mon, 7 Sep 2015, Arnd Bergmann wrote:
>
> > On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote:
> > > If 768MB targets were common place then it could be worth changing the
> > > default vmalloc size to accommodate this
On Mon, 7 Sep 2015, Arnd Bergmann wrote:
> On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote:
> > If 768MB targets were common place then it could be worth changing the
> > default vmalloc size to accommodate this memory size and testing all the
> > other targets to make sure no
On Mon, 7 Sep 2015, Arnd Bergmann wrote:
> On Monday 07 September 2015 11:34:36 Nicolas Pitre wrote:
> >
> > That shifts the risk to user space though. But if there is a regression
> > there, it will manifest itself on all systems and not only with some
> > particular hardware.
>
> I'd
On Monday 07 September 2015 11:34:36 Nicolas Pitre wrote:
>
> That shifts the risk to user space though. But if there is a regression
> there, it will manifest itself on all systems and not only with some
> particular hardware.
I'd consider that a good thing, as it makes it easier to test
On Mon, 7 Sep 2015, Arnd Bergmann wrote:
> Given how much more common 1GB hardware configurations are compared to 768MB
> configuration, we could however think about adding a VMSPLIT_3G_OPT option
> that x86 has (also VMSPLIT_2_75G on ARCH_TILE), to allow using the entire
> 1GB of lowmem without
On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote:
> If 768MB targets were common place then it could be worth changing the
> default vmalloc size to accommodate this memory size and testing all the
> other targets to make sure no regressions are introduced. But given it
> is easy to
On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote:
> If 768MB targets were common place then it could be worth changing the
> default vmalloc size to accommodate this memory size and testing all the
> other targets to make sure no regressions are introduced. But given it
> is easy to
On Mon, 7 Sep 2015, Arnd Bergmann wrote:
> Given how much more common 1GB hardware configurations are compared to 768MB
> configuration, we could however think about adding a VMSPLIT_3G_OPT option
> that x86 has (also VMSPLIT_2_75G on ARCH_TILE), to allow using the entire
> 1GB of lowmem without
On Monday 07 September 2015 11:34:36 Nicolas Pitre wrote:
>
> That shifts the risk to user space though. But if there is a regression
> there, it will manifest itself on all systems and not only with some
> particular hardware.
I'd consider that a good thing, as it makes it easier to test
On Mon, 7 Sep 2015, Arnd Bergmann wrote:
> On Monday 07 September 2015 11:34:36 Nicolas Pitre wrote:
> >
> > That shifts the risk to user space though. But if there is a regression
> > there, it will manifest itself on all systems and not only with some
> > particular hardware.
>
> I'd
On Mon, Sep 07, 2015 at 03:40:36PM -0400, Nicolas Pitre wrote:
> On Mon, 7 Sep 2015, Arnd Bergmann wrote:
>
> > On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote:
> > > If 768MB targets were common place then it could be worth changing the
> > > default vmalloc size to accommodate this
On Tue, 8 Sep 2015, Russell King - ARM Linux wrote:
> On Mon, Sep 07, 2015 at 03:40:36PM -0400, Nicolas Pitre wrote:
> > On Mon, 7 Sep 2015, Arnd Bergmann wrote:
> >
> > > On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote:
> > > > If 768MB targets were common place then it could be
On Mon, 7 Sep 2015, Arnd Bergmann wrote:
> On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote:
> > If 768MB targets were common place then it could be worth changing the
> > default vmalloc size to accommodate this memory size and testing all the
> > other targets to make sure no
On Thu, 3 Sep 2015, Yongtaek Lee wrote:
> So i summarize my opinion again.
>
> Current status.
>
> 768MB, no CONFIG_HIGHMEM and no vmalloc=size
> lowmem : 0MB ~ 760MB
> vmalloc : 768MB ~ VMALLOC_END
> => waste 8MB because 760MB ~ 768MB is hole
>
> 1GB, no CONFIG_HIGHMEM and no vmalloc=size
> Wrong, there is no such "rule".
> If we apply that rule, then if you have 1GB of RAM, it will fill from
> 0xc000 to 0x inclusive. There will be _zero_ bytes of
> vmalloc space. There will be _zero_ bytes of IO mappings. There won't
> even be a vectors page, so the kernel _will_
> Wrong, there is no such "rule".
> If we apply that rule, then if you have 1GB of RAM, it will fill from
> 0xc000 to 0x inclusive. There will be _zero_ bytes of
> vmalloc space. There will be _zero_ bytes of IO mappings. There won't
> even be a vectors page, so the kernel _will_
On Thu, 3 Sep 2015, Yongtaek Lee wrote:
> So i summarize my opinion again.
>
> Current status.
>
> 768MB, no CONFIG_HIGHMEM and no vmalloc=size
> lowmem : 0MB ~ 760MB
> vmalloc : 768MB ~ VMALLOC_END
> => waste 8MB because 760MB ~ 768MB is hole
>
> 1GB, no CONFIG_HIGHMEM and no vmalloc=size
default value of VMALLOC_START was set 0xf000 for ARM by commit
0536bdf3. It leads lowmem end address 0xef80 not 0xf000.
VMALLOC_END - (240 << 20) - VMALLOC_OFFSET)
0xff00 - 0x0f00 - 0x0080 = 0xef80
In case of 768MB ram without CONFIG_HIGHMEM=y, last 8MB could not be
default value of VMALLOC_START was set 0xf000 for ARM by commit
0536bdf3. It leads lowmem end address 0xef80 not 0xf000.
VMALLOC_END - (240 << 20) - VMALLOC_OFFSET)
0xff00 - 0x0f00 - 0x0080 = 0xef80
In case of 768MB ram without CONFIG_HIGHMEM=y, last 8MB could not be
24 matches
Mail list logo
