[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210315075113.GD4136862@infradead.org>
Date: Mon, 15 Mar 2021 07:51:13 +0000
From: Christoph Hellwig <hch@...radead.org>
To: Alistair Popple <apopple@...dia.com>
Cc: linux-mm@...ck.org, nouveau@...ts.freedesktop.org,
bskeggs@...hat.com, akpm@...ux-foundation.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
kvm-ppc@...r.kernel.org, dri-devel@...ts.freedesktop.org,
jhubbard@...dia.com, rcampbell@...dia.com, jglisse@...hat.com,
jgg@...dia.com, hch@...radead.org, daniel@...ll.ch,
willy@...radead.org
Subject: Re: [PATCH v6 8/8] nouveau/svm: Implement atomic SVM access
> - /*XXX: atomic? */
> - return (fa->access == 0 || fa->access == 3) -
> - (fb->access == 0 || fb->access == 3);
> + /* Atomic access (2) has highest priority */
> + return (-1*(fa->access == 2) + (fa->access == 0 || fa->access == 3)) -
> + (-1*(fb->access == 2) + (fb->access == 0 || fb->access == 3));
This looks really unreabable. If the magic values 0, 2 and 3 had names
it might become a little more understadable, then factor the duplicated
calculation of the priority value into a helper and we'll have code that
mere humans can understand..
> + mutex_lock(&svmm->mutex);
> + if (mmu_interval_read_retry(¬ifier->notifier,
> + notifier_seq)) {
> + mutex_unlock(&svmm->mutex);
> + continue;
> + }
> + break;
> + }
This looks good, why not:
mutex_lock(&svmm->mutex);
if (!mmu_interval_read_retry(¬ifier->notifier,
notifier_seq))
break;
mutex_unlock(&svmm->mutex);
}
Powered by blists - more mailing lists