[LSF/MM ATTEND][LSF/MM TOPIC] Address range mirroring enhancement

[LSF/MM ATTEND][LSF/MM TOPIC] Address range mirroring enhancement

[Izumi, Taku]

Hi,

I'd like to atten LSF/MM 2016 and I'd like to discuss "Address range mirroring" topic.
The current status of Address range mirroring in Linux is:
  - bootmem will be allocated from mirroring range
  - kernel memorry will be allocated from mirroring range 
    by specifying kernelcore=mirror 

I think we can enhance Adderss range mirroring more.
For excample,
  - The handling of mirrored memory exhaustion case
  - The option any user memory can be allocated from mirrored memory
  and so on.

I'd like to discuss this topic.

Sincerely,
Taku Izumi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [LSF/MM ATTEND][LSF/MM TOPIC] Address range mirroring enhancement

[Balbir Singh]

On 29/02/16 13:12, Izumi, Taku wrote:
> Hi,
>
> I'd like to atten LSF/MM 2016 and I'd like to discuss "Address range mirroring" topic.
> The current status of Address range mirroring in Linux is:
>   - bootmem will be allocated from mirroring range
>   - kernel memorry will be allocated from mirroring range 
>     by specifying kernelcore=mirror 
>
> I think we can enhance Adderss range mirroring more.
> For excample,
>   - The handling of mirrored memory exhaustion case
>   - The option any user memory can be allocated from mirrored memory
>   and so on.
>
> I'd like to discuss this topic.
>
>

Sounds interesting! Do you have a detailed write up on the topic?

Balbir Singh.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

RE: [LSF/MM ATTEND][LSF/MM TOPIC] Address range mirroring enhancement

[Izumi, Taku]

> > Hi,
> >
> > I'd like to atten LSF/MM 2016 and I'd like to discuss "Address range mirroring" topic.
> > The current status of Address range mirroring in Linux is:
> >   - bootmem will be allocated from mirroring range
> >   - kernel memorry will be allocated from mirroring range
> >     by specifying kernelcore=mirror
> >
> > I think we can enhance Adderss range mirroring more.
> > For excample,
> >   - The handling of mirrored memory exhaustion case
> >   - The option any user memory can be allocated from mirrored memory
> >   and so on.
> >
> > I'd like to discuss this topic.
> >
> >
> 
> Sounds interesting! Do you have a detailed write up on the topic?

  Give me some time to make a detailed write up.

  Former discussions are:
   http://thread.gmane.org/gmane.linux.kernel/1884223
   https://lkml.org/lkml/2015/6/4/359
   http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg992524.html
   http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg997069.html
   https://lkml.org/lkml/2015/11/27/18
   https://lkml.org/lkml/2015/12/8/836

 Sincerely,
 Taku Izumi

> 
> Balbir Singh.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [LSF/MM ATTEND][LSF/MM TOPIC] Address range mirroring enhancement

[Dave Hansen]

On 03/01/2016 09:31 PM, Izumi, Taku wrote:
>> > > I'd like to atten LSF/MM 2016 and I'd like to discuss "Address range mirroring" topic.
>> > > The current status of Address range mirroring in Linux is:
>> > >   - bootmem will be allocated from mirroring range
>> > >   - kernel memorry will be allocated from mirroring range
>> > >     by specifying kernelcore=mirror
>> > >
>> > > I think we can enhance Adderss range mirroring more.
>> > > For excample,
>> > >   - The handling of mirrored memory exhaustion case
>> > >   - The option any user memory can be allocated from mirrored memory
>> > >   and so on.

It sounds like there was some good discussions of this at LSF/MM:

	https://lwn.net/Articles/684866/

One thing I wanted to add: There's an Intel platform (Knights Landing
aka Xeon Phi) that has some on-package memory.  It's higher-bandwidth
than normal DRAM, but it shows up as a really slow, remote NUMA node.
Instead of needing to come up with new syscalls for allocating from this
new memory, applications just use the plain old NUMA APIs.

While this doesn't help any of the other issues for mirroring (the
fallback and exhaustion problems), is there a reason we shouldn't use
the NUMA APIs for this?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>