Re: [PATCH 0/4] kernfs: proposed locking and concurrency improvement

2020-05-27 Thread Rick Lindsley
On 5/24/20 11:16 PM, Greg Kroah-Hartman wrote: Independant of your kernfs changes, why do we really need to represent all of this memory with that many different "memory objects"? What is that providing to userspace? I remember Ben Herrenschmidt did a lot of work on some of the kernfs and

Re: [PATCH 0/4] kernfs: proposed locking and concurrency improvement

2020-05-25 Thread Greg Kroah-Hartman
On Mon, May 25, 2020 at 03:23:35PM +0800, Ian Kent wrote: > On Mon, 2020-05-25 at 08:16 +0200, Greg Kroah-Hartman wrote: > > On Mon, May 25, 2020 at 01:46:59PM +0800, Ian Kent wrote: > > > For very large systems with hundreds of CPUs and TBs of RAM booting > > > can > > > take a very long time. >

Re: [PATCH 0/4] kernfs: proposed locking and concurrency improvement

2020-05-25 Thread Ian Kent
On Mon, 2020-05-25 at 08:16 +0200, Greg Kroah-Hartman wrote: > On Mon, May 25, 2020 at 01:46:59PM +0800, Ian Kent wrote: > > For very large systems with hundreds of CPUs and TBs of RAM booting > > can > > take a very long time. > > > > Initial reports showed that booting a configuration of

Re: [PATCH 0/4] kernfs: proposed locking and concurrency improvement

2020-05-25 Thread Greg Kroah-Hartman
On Mon, May 25, 2020 at 01:46:59PM +0800, Ian Kent wrote: > For very large systems with hundreds of CPUs and TBs of RAM booting can > take a very long time. > > Initial reports showed that booting a configuration of several hundred > CPUs and 64TB of RAM would take more than 30 minutes and

[PATCH 0/4] kernfs: proposed locking and concurrency improvement

2020-05-24 Thread Ian Kent
For very large systems with hundreds of CPUs and TBs of RAM booting can take a very long time. Initial reports showed that booting a configuration of several hundred CPUs and 64TB of RAM would take more than 30 minutes and require kernel parameters of udev.children-max=1024