On 03/30/2016 08:58 PM, Samuel Thibault wrote:
Ok, I hadn't understood what you meant. Actually, you perhaps
don't even need to lock the map before calling vm_map_lookup: does
gsync_fill_wait really need to do the valid_access_p() call itself? We
can make functions call gsync_fill_wait, then lo
Hello,
Agustina Arzille, on Wed 30 Mar 2016 20:38:21 -0300, wrote:
> On 03/30/2016 08:07 PM, Samuel Thibault wrote:
> >>For shared gsync objects, I'm using vm_map_lookup to find out the
> >>vm object and offset. The problem is that said function expects the map
> >>to be unlocked
> >Really?
> >
>
Hello, Samuel.
On 03/30/2016 08:07 PM, Samuel Thibault wrote:
For shared gsync objects, I'm using vm_map_lookup to find out the
vm object and offset. The problem is that said function expects the map
to be unlocked
Really?
It starts with locking it, and finishes with unlocking it, and the lock
Hello,
Agustina Arzille, on Tue 29 Mar 2016 22:37:27 -0300, wrote:
> As for Linux, they too use a global hash table, but its size is determined
> by the number of CPUs (The actual size is 256 * NCPUS).
Ok. Doing the same is probably a good start.
> For shared gsync objects, I'm using vm_map_look
Hi!
On Sun, 31 Aug 2014 18:41:41 +0200, Samuel Thibault
wrote:
> Matthias Klose, le Sun 31 Aug 2014 18:39:21 +0200, a écrit :
> > Am 31.08.2014 um 03:10 schrieb Samuel Thibault:
> > > guess that will just fix all our issues... I'll then commit that and
> > > push upstream.
> >
> > is this nece
