lkml.org 
[lkml]   [2019]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Re: [Xen-devel] [PATCH v12 2/5] xenbus/backend: Protect xenbus callback with lock
Date
On Wed, 18 Dec 2019 13:27:37 +0100 "Jürgen Groß" <jgross@suse.com> wrote:

> On 18.12.19 11:42, SeongJae Park wrote:
> > From: SeongJae Park <sjpark@amazon.de>
> >
> > 'reclaim_memory' callback can race with a driver code as this callback
> > will be called from any memory pressure detected context. To deal with
> > the case, this commit adds a spinlock in the 'xenbus_device'. Whenever
> > 'reclaim_memory' callback is called, the lock of the device which passed
> > to the callback as its argument is locked. Thus, drivers registering
> > their 'reclaim_memory' callback should protect the data that might race
> > with the callback with the lock by themselves.
>
> Any reason you don't take the lock around the .probe() and .remove()
> calls of the backend (xenbus_dev_probe() and xenbus_dev_remove())? This
> would eliminate the need to do that in each backend instead.

First of all, I would like to keep the critical section as small as possible.
With my small test, I could see slightly increasing memory pressure as the
critical section becomes wider. Also, some drivers might share the data their
'reclaim_memory' callback touches with other functions. I think only the
driver owners can know what data is shared and what is the minimum critical
section to protect it.

If you think differently or I am missing something, please let me know.


Thanks,
SeongJae Park

>
>
> Juergen

\
 
 \ /
  Last update: 2019-12-18 13:44    [W:0.038 / U:1.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site