> On 1 Jun 2016, at 9:44 PM, Martin Pieuchot wrote:
>
> On 01/06/16(Wed) 19:27, David Gwynne wrote:
>>
>>> On 1 Jun 2016, at 4:13 PM, Martin Pieuchot wrote:
>>>
>>> On 01/06/16(Wed) 15:31, David Gwynne wrote:
currently it leaves early if it is the last entry being removed,
which is
On 01/06/16(Wed) 19:27, David Gwynne wrote:
>
> > On 1 Jun 2016, at 4:13 PM, Martin Pieuchot wrote:
> >
> > On 01/06/16(Wed) 15:31, David Gwynne wrote:
> >> currently it leaves early if it is the last entry being removed,
> >> which is an optimisation. in the future it is possible for another
>
> On 1 Jun 2016, at 4:13 PM, Martin Pieuchot wrote:
>
> On 01/06/16(Wed) 15:31, David Gwynne wrote:
>> currently it leaves early if it is the last entry being removed,
>> which is an optimisation. in the future it is possible for another
>> cpu to have a reference to the table while the last ref
On 01/06/16(Wed) 15:31, David Gwynne wrote:
> currently it leaves early if it is the last entry being removed,
> which is an optimisation. in the future it is possible for another
> cpu to have a reference to the table while the last reference is
> being dropped, so we need to scrub it in case it g
currently it leaves early if it is the last entry being removed,
which is an optimisation. in the future it is possible for another
cpu to have a reference to the table while the last reference is
being dropped, so we need to scrub it in case it gets read.
ok?
Index: art.c
===
