* gfn_lock() seems useless.
@ 2016-02-02 6:54 Zhangbo (Oscar)
2016-02-02 16:26 ` Jan Beulich
0 siblings, 1 reply; 4+ messages in thread
From: Zhangbo (Oscar) @ 2016-02-02 6:54 UTC (permalink / raw)
To: andres@lagarcavilla.org, xen-devel@lists.xen.org
Cc: Herongguang (Stephen), Linqiangmin, Huangpeng (Peter),
Wangyufei (James)
Hi all:
In patch e1e40bccee7490a01ac7d1f759ec2bbafd3c7185, it says that"many routines can logically assert holding the p2m *FOR A SPECIFIC GFN.*" ,
But I find out that it did nothing for locking a single gfn, in fact it still locked the entire p2m list.
-#define p2m_lock_recursive(p) mm_lock_recursive(p2m, &(p)->lock)
+#define gfn_lock(p,g,o) mm_lock_recursive(p2m, &(p)->lock) //'g' is not used. The entire p2m list is locked.
Do we have any plan to lock a specific gfn? If so, how ? If not, shall we redefine the macro?
Thans.
Oscar.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: gfn_lock() seems useless.
2016-02-02 6:54 gfn_lock() seems useless Zhangbo (Oscar)
@ 2016-02-02 16:26 ` Jan Beulich
2016-02-03 4:55 ` Andres Lagar Cavilla
0 siblings, 1 reply; 4+ messages in thread
From: Jan Beulich @ 2016-02-02 16:26 UTC (permalink / raw)
To: Zhangbo (Oscar)
Cc: Wangyufei (James), Huangpeng (Peter), xen-devel@lists.xen.org,
Linqiangmin, andres@lagarcavilla.org, Herongguang (Stephen)
>>> On 02.02.16 at 07:54, <oscar.zhangbo@huawei.com> wrote:
> Hi all:
> In patch e1e40bccee7490a01ac7d1f759ec2bbafd3c7185, it says that"many
> routines can logically assert holding the p2m *FOR A SPECIFIC GFN.*" ,
> But I find out that it did nothing for locking a single gfn, in fact it
> still locked the entire p2m list.
>
> -#define p2m_lock_recursive(p) mm_lock_recursive(p2m, &(p)->lock)
> +#define gfn_lock(p,g,o) mm_lock_recursive(p2m, &(p)->lock) //'g' is not
> used. The entire p2m list is locked.
>
>
> Do we have any plan to lock a specific gfn?
This indeed is a long term plan, but afaik no-one is currently
doing any work in that direction.
Jan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: gfn_lock() seems useless.
2016-02-02 16:26 ` Jan Beulich
@ 2016-02-03 4:55 ` Andres Lagar Cavilla
2016-02-03 15:01 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 4+ messages in thread
From: Andres Lagar Cavilla @ 2016-02-03 4:55 UTC (permalink / raw)
To: Jan Beulich
Cc: Wangyufei (James), Zhangbo (Oscar), Huangpeng (Peter),
xen-devel@lists.xen.org, Linqiangmin, Herongguang (Stephen)
[-- Attachment #1.1: Type: text/plain, Size: 1010 bytes --]
At the time, I had a patch queue for splitting the p2m locking into a tree
of per-2M locks. Very similar to Linux's split locks. I scaffolded the
macros to allow for that expansion. Then, I got pulled onto other things.
Andres
On Tue, Feb 2, 2016 at 8:26 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >>> On 02.02.16 at 07:54, <oscar.zhangbo@huawei.com> wrote:
> > Hi all:
> > In patch e1e40bccee7490a01ac7d1f759ec2bbafd3c7185, it says that"many
> > routines can logically assert holding the p2m *FOR A SPECIFIC GFN.*" ,
> > But I find out that it did nothing for locking a single gfn, in fact it
> > still locked the entire p2m list.
> >
> > -#define p2m_lock_recursive(p) mm_lock_recursive(p2m, &(p)->lock)
> > +#define gfn_lock(p,g,o) mm_lock_recursive(p2m, &(p)->lock) //'g'
> is not
> > used. The entire p2m list is locked.
> >
> >
> > Do we have any plan to lock a specific gfn?
>
> This indeed is a long term plan, but afaik no-one is currently
> doing any work in that direction.
>
> Jan
>
>
[-- Attachment #1.2: Type: text/html, Size: 1600 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: gfn_lock() seems useless.
2016-02-03 4:55 ` Andres Lagar Cavilla
@ 2016-02-03 15:01 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 4+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-02-03 15:01 UTC (permalink / raw)
To: Andres Lagar Cavilla
Cc: Zhangbo (Oscar), Huangpeng (Peter), xen-devel@lists.xen.org,
Herongguang (Stephen), Linqiangmin, Jan Beulich,
Wangyufei (James)
On Tue, Feb 02, 2016 at 08:55:50PM -0800, Andres Lagar Cavilla wrote:
> At the time, I had a patch queue for splitting the p2m locking into a tree
> of per-2M locks. Very similar to Linux's split locks. I scaffolded the
> macros to allow for that expansion. Then, I got pulled onto other things.
Could you post/point folks to your patch queue?
Thanks.
>
> Andres
>
> On Tue, Feb 2, 2016 at 8:26 AM, Jan Beulich <JBeulich@suse.com> wrote:
>
> > >>> On 02.02.16 at 07:54, <oscar.zhangbo@huawei.com> wrote:
> > > Hi all:
> > > In patch e1e40bccee7490a01ac7d1f759ec2bbafd3c7185, it says that"many
> > > routines can logically assert holding the p2m *FOR A SPECIFIC GFN.*" ,
> > > But I find out that it did nothing for locking a single gfn, in fact it
> > > still locked the entire p2m list.
> > >
> > > -#define p2m_lock_recursive(p) mm_lock_recursive(p2m, &(p)->lock)
> > > +#define gfn_lock(p,g,o) mm_lock_recursive(p2m, &(p)->lock) //'g'
> > is not
> > > used. The entire p2m list is locked.
> > >
> > >
> > > Do we have any plan to lock a specific gfn?
> >
> > This indeed is a long term plan, but afaik no-one is currently
> > doing any work in that direction.
> >
> > Jan
> >
> >
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-02-03 15:01 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-02-02 6:54 gfn_lock() seems useless Zhangbo (Oscar)
2016-02-02 16:26 ` Jan Beulich
2016-02-03 4:55 ` Andres Lagar Cavilla
2016-02-03 15:01 ` Konrad Rzeszutek Wilk
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).