Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Thu, 16 Mar 2017, Thomas Gleixner wrote: > Why do we need yet another mechanism to represent something which looks > like a file instead of simply using existing mechanisms and extend them? You are right. I also recognized during the discussion with Andy, Chris, Matthew, Luck, Rich and the

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Thu, 16 Mar 2017, Thomas Gleixner wrote: > On Thu, 16 Mar 2017, Till Smejkal wrote: > > On Thu, 16 Mar 2017, Thomas Gleixner wrote: > > > Why do we need yet another mechanism to represent something which looks > > > like a file instead of simply using existing mechanisms and extend them? > > >

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Thu, 16 Mar 2017, Till Smejkal wrote: > On Thu, 16 Mar 2017, Thomas Gleixner wrote: > > Why do we need yet another mechanism to represent something which looks > > like a file instead of simply using existing mechanisms and extend them? > > You are right. I also recognized during the

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Wed, 15 Mar 2017, Till Smejkal wrote: > On Wed, 15 Mar 2017, Andy Lutomirski wrote: > > > VAS segments on the other side would provide a functionality to > > > achieve the same without the need of any mounted filesystem. However, > > > I agree, that this is just a small advantage compared to

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Wed, 15 Mar 2017, Luck, Tony wrote: > On Wed, Mar 15, 2017 at 03:02:34PM -0700, Till Smejkal wrote: > > I don't agree here. VAS segments are basically in-memory files that are > > handled by > > the kernel directly without using a file system. Hence, if an application > > uses a VAS > >

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Wed, Mar 15, 2017 at 03:02:34PM -0700, Till Smejkal wrote: > I don't agree here. VAS segments are basically in-memory files that are > handled by > the kernel directly without using a file system. Hence, if an application > uses a VAS > segment to store data the same rules apply as if it uses

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Wed, 15 Mar 2017, Andy Lutomirski wrote: > On Wed, Mar 15, 2017 at 12:44 PM, Till Smejkal > wrote: > > On Wed, 15 Mar 2017, Andy Lutomirski wrote: > >> > One advantage of VAS segments is that they can be globally queried by > >> > user programs > >> > which means

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Wed, 15 Mar 2017, Rich Felker wrote: > On Wed, Mar 15, 2017 at 12:44:47PM -0700, Till Smejkal wrote: > > On Wed, 15 Mar 2017, Andy Lutomirski wrote: > > > > One advantage of VAS segments is that they can be globally queried by > > > > user programs > > > > which means that VAS segments can be

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Wed, Mar 15, 2017 at 12:44 PM, Till Smejkal wrote: > On Wed, 15 Mar 2017, Andy Lutomirski wrote: >> > One advantage of VAS segments is that they can be globally queried by user >> > programs >> > which means that VAS segments can be shared by applications that not

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Wed, Mar 15, 2017 at 12:44:47PM -0700, Till Smejkal wrote: > On Wed, 15 Mar 2017, Andy Lutomirski wrote: > > > One advantage of VAS segments is that they can be globally queried by > > > user programs > > > which means that VAS segments can be shared by applications that not > > > necessarily

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Wed, 15 Mar 2017, Andy Lutomirski wrote: > > One advantage of VAS segments is that they can be globally queried by user > > programs > > which means that VAS segments can be shared by applications that not > > necessarily have > > to be related. If I am not mistaken, MAP_SHARED of pure in

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Wed, Mar 15, 2017 at 09:51:31AM -0700, Andy Lutomirski wrote: > > VAS segments on the other side allow sharing of pure in memory data by > > arbitrary related tasks without the need of a file. This becomes especially > > interesting if one combines VAS segments with non-volatile memory since

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Tue, Mar 14, 2017 at 9:12 AM, Till Smejkal wrote: > On Mon, 13 Mar 2017, Andy Lutomirski wrote: >> On Mon, Mar 13, 2017 at 7:07 PM, Till Smejkal >> wrote: >> > On Mon, 13 Mar 2017, Andy Lutomirski wrote: >> >> This sounds rather

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Tue, 14 Mar 2017, Chris Metcalf wrote: > On 3/14/2017 12:12 PM, Till Smejkal wrote: > > On Mon, 13 Mar 2017, Andy Lutomirski wrote: > > > On Mon, Mar 13, 2017 at 7:07 PM, Till Smejkal > > > wrote: > > > > On Mon, 13 Mar 2017, Andy Lutomirski wrote: > > > > > This

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On 3/14/2017 12:12 PM, Till Smejkal wrote: On Mon, 13 Mar 2017, Andy Lutomirski wrote: On Mon, Mar 13, 2017 at 7:07 PM, Till Smejkal wrote: On Mon, 13 Mar 2017, Andy Lutomirski wrote: This sounds rather complicated. Getting TLB flushing right seems tricky. Why

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Mon, 13 Mar 2017, Andy Lutomirski wrote: > On Mon, Mar 13, 2017 at 7:07 PM, Till Smejkal > wrote: > > On Mon, 13 Mar 2017, Andy Lutomirski wrote: > >> This sounds rather complicated. Getting TLB flushing right seems > >> tricky. Why not just map the same thing

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Mon, Mar 13, 2017 at 7:07 PM, Till Smejkal wrote: > On Mon, 13 Mar 2017, Andy Lutomirski wrote: >> This sounds rather complicated. Getting TLB flushing right seems >> tricky. Why not just map the same thing into multiple mms? > > This is exactly what happens at

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Mon, 13 Mar 2017, Andy Lutomirski wrote: > On Mon, Mar 13, 2017 at 3:14 PM, Till Smejkal > wrote: > > This patchset extends the kernel memory management subsystem with a new > > type of address spaces (called VAS) which can be created and destroyed > >

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Tue, 14 Mar 2017, Richard Henderson wrote: > On 03/14/2017 10:39 AM, Till Smejkal wrote: > > > Is this an indication that full virtual address spaces are useless? It > > > would seem like if you only use virtual address segments then you avoid > > > all > > > of the problems with executing

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On 03/14/2017 10:39 AM, Till Smejkal wrote: Is this an indication that full virtual address spaces are useless? It would seem like if you only use virtual address segments then you avoid all of the problems with executing code, active stacks, and brk. What do you mean with *virtual address

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Mon, Mar 13, 2017 at 3:14 PM, Till Smejkal wrote: > This patchset extends the kernel memory management subsystem with a new > type of address spaces (called VAS) which can be created and destroyed > independently of processes by a user in the system. During its

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Tue, 14 Mar 2017, Richard Henderson wrote: > On 03/14/2017 08:14 AM, Till Smejkal wrote: > > At the current state of the development, first class virtual address spaces > > have one limitation, that we haven't been able to solve so far. The feature > > allows, that different threads of the same

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On 03/14/2017 08:14 AM, Till Smejkal wrote: At the current state of the development, first class virtual address spaces have one limitation, that we haven't been able to solve so far. The feature allows, that different threads of the same process can execute in different AS at the same time.