Re: [RFC v2 2/2] [MOCKUP] sched/mm: Lightweight lazy mm refcounting

2020-12-04 Thread Nicholas Piggin
Excerpts from Andy Lutomirski's message of December 5, 2020 12:37 am: > > >> On Dec 3, 2020, at 11:54 PM, Nicholas Piggin wrote: >> >> Excerpts from Andy Lutomirski's message of December 4, 2020 3:26 pm: >>> This is a mockup. It's designed to illustrate the algorithm and how the >>> code migh

Re: [RFC v2 2/2] [MOCKUP] sched/mm: Lightweight lazy mm refcounting

2020-12-04 Thread Andy Lutomirski
> On Dec 3, 2020, at 11:54 PM, Nicholas Piggin wrote: > > Excerpts from Andy Lutomirski's message of December 4, 2020 3:26 pm: >> This is a mockup. It's designed to illustrate the algorithm and how the >> code might be structured. There are several things blatantly wrong with >> it: >> >>

Re: [RFC v2 2/2] [MOCKUP] sched/mm: Lightweight lazy mm refcounting

2020-12-03 Thread Nicholas Piggin
Excerpts from Andy Lutomirski's message of December 4, 2020 3:26 pm: > This is a mockup. It's designed to illustrate the algorithm and how the > code might be structured. There are several things blatantly wrong with > it: > > The coding stype is not up to kernel standards. I have prototypes in

[RFC v2 2/2] [MOCKUP] sched/mm: Lightweight lazy mm refcounting

2020-12-03 Thread Andy Lutomirski
This is a mockup. It's designed to illustrate the algorithm and how the code might be structured. There are several things blatantly wrong with it: The coding stype is not up to kernel standards. I have prototypes in the wrong places and other hacks. There's a problem with mm_cpumask() not bei