On Tue, Jun 25, 2019 at 07:20:12AM +, Koenig, Christian wrote:
> Am 24.06.19 um 16:41 schrieb Daniel Vetter:
> > On Mon, Jun 24, 2019 at 03:58:00PM +0200, Christian König wrote:
> >> Am 24.06.19 um 13:23 schrieb Koenig, Christian:
> >>> Am 21.06.19 um 18:27 schrieb Daniel Vetter:
> >>>
>
Am 24.06.19 um 16:41 schrieb Daniel Vetter:
> On Mon, Jun 24, 2019 at 03:58:00PM +0200, Christian König wrote:
>> Am 24.06.19 um 13:23 schrieb Koenig, Christian:
>>> Am 21.06.19 um 18:27 schrieb Daniel Vetter:
>>>
So I pondered a few ideas while working out:
1) We drop this
On Mon, Jun 24, 2019 at 03:58:00PM +0200, Christian König wrote:
> Am 24.06.19 um 13:23 schrieb Koenig, Christian:
> > Am 21.06.19 um 18:27 schrieb Daniel Vetter:
> >
> > > So I pondered a few ideas while working out:
> > >
> > > 1) We drop this filtering. Importer needs to keep track of all its
On Mon, Jun 24, 2019 at 11:23:34AM +, Koenig, Christian wrote:
> Am 21.06.19 um 18:27 schrieb Daniel Vetter:
> >>> Your scenario here is new, and iirc my suggestion back then was to
> >>> count the number of pending mappings so you don't go around calling
> >>> ->invalidate on mappings that
Am 24.06.19 um 13:23 schrieb Koenig, Christian:
Am 21.06.19 um 18:27 schrieb Daniel Vetter:
So I pondered a few ideas while working out:
1) We drop this filtering. Importer needs to keep track of all its
mappings and filter out invalidates that aren't for that specific importer
(either
Am 21.06.19 um 18:27 schrieb Daniel Vetter:
>>> Your scenario here is new, and iirc my suggestion back then was to
>>> count the number of pending mappings so you don't go around calling
>>> ->invalidate on mappings that don't exist.
>> Well the key point is we don't call invalidate on mappings,
On Fri, Jun 21, 2019 at 02:06:54PM +0200, Christian König wrote:
> Am 21.06.19 um 12:32 schrieb Daniel Vetter:
> > On Fri, Jun 21, 2019 at 11:55 AM Christian König
> > wrote:
> > > Am 21.06.19 um 11:20 schrieb Daniel Vetter:
> > > > On Tue, Jun 18, 2019 at 01:54:50PM +0200, Christian König wrote:
Am 21.06.19 um 12:32 schrieb Daniel Vetter:
On Fri, Jun 21, 2019 at 11:55 AM Christian König
wrote:
Am 21.06.19 um 11:20 schrieb Daniel Vetter:
On Tue, Jun 18, 2019 at 01:54:50PM +0200, Christian König wrote:
[SNIP]
Imo the below semantics would be much cleaner:
- invalidate may add new
On Fri, Jun 21, 2019 at 11:55 AM Christian König
wrote:
>
> Am 21.06.19 um 11:20 schrieb Daniel Vetter:
> > On Tue, Jun 18, 2019 at 01:54:50PM +0200, Christian König wrote:
> >> On the exporter side we add optional explicit pinning callbacks. If those
> >> callbacks are implemented the framework
Am 21.06.19 um 11:20 schrieb Daniel Vetter:
On Tue, Jun 18, 2019 at 01:54:50PM +0200, Christian König wrote:
On the exporter side we add optional explicit pinning callbacks. If those
callbacks are implemented the framework no longer caches sg tables and the
map/unmap callbacks are always called
On Tue, Jun 18, 2019 at 01:54:50PM +0200, Christian König wrote:
> On the exporter side we add optional explicit pinning callbacks. If those
> callbacks are implemented the framework no longer caches sg tables and the
> map/unmap callbacks are always called with the lock of the reservation object
11 matches
Mail list logo
