From: Alex Kogan <alex.kogan@oracle.com> To: Waiman Long <longman@redhat.com> Cc: linux@armlinux.org.uk, peterz@infradead.org, mingo@redhat.com, will.deacon@arm.com, arnd@arndb.de, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, bp@alien8.de, hpa@zytor.com, x86@kernel.org, guohanjun@huawei.com, jglauber@marvell.com, steven.sistare@oracle.com, daniel.m.jordan@oracle.com, dave.dice@oracle.com Subject: Re: [PATCH v9 4/5] locking/qspinlock: Introduce starvation avoidance into CNA Date: Thu, 23 Jan 2020 18:39:36 -0500 [thread overview] Message-ID: <1B2B46E9-651E-4BA5-988A-924AE3E72C00@oracle.com> (raw) In-Reply-To: <5f865b62-4867-2c7b-715a-0605759e647f@redhat.com> > On Jan 23, 2020, at 3:39 PM, Waiman Long <longman@redhat.com> wrote: > > On 1/23/20 2:55 PM, Waiman Long wrote: >> Playing with lock event counts, I would like you to change the meaning >> intra_count parameter that you are tracking. Instead of tracking the >> number of times a lock is passed to a waiter of the same node >> consecutively, I would like you to track the number of times the head >> waiter in the secondary queue has given up its chance to acquire the >> lock because a later waiter has jumped the queue and acquire the lock >> before it. Isn’t that the same thing? Note that we keep track of the number of intra-node lock transfers only when the secondary queue is not empty. >> This value determines the worst case latency that a secondary >> queue waiter can experience. So > > Well, that is not strictly true as a a waiter in the middle of the > secondary queue can go back and fro between the queues for a number of > times. Of course, if we can ensure that when a FLUSH_SECONDARY_QUEUE is > issued, those waiters that were in the secondary queue won't be put back > into the secondary queue again. This will not work as intended when we have more than 2 nodes. That is, if we have threads from node A & B in the secondary queue, and then the queue is flushed and its head (say, from node A) gets the lock, we want to push threads from node B back into the secondary queue, to keep the lock on node A. And if we have only 2 nodes, a waiter in the middle of the secondary queue will never go back into the secondary queue, even if the threshold is small. This is because we flush the secondary queue by putting all its waiters in the front of the main queue, and the secondary queue will remain empty at least until we reach a thread from another node. Regards, — Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alex Kogan <alex.kogan@oracle.com> To: Waiman Long <longman@redhat.com> Cc: linux-arch@vger.kernel.org, guohanjun@huawei.com, arnd@arndb.de, peterz@infradead.org, dave.dice@oracle.com, jglauber@marvell.com, x86@kernel.org, will.deacon@arm.com, linux@armlinux.org.uk, linux-kernel@vger.kernel.org, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, steven.sistare@oracle.com, tglx@linutronix.de, daniel.m.jordan@oracle.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v9 4/5] locking/qspinlock: Introduce starvation avoidance into CNA Date: Thu, 23 Jan 2020 18:39:36 -0500 [thread overview] Message-ID: <1B2B46E9-651E-4BA5-988A-924AE3E72C00@oracle.com> (raw) In-Reply-To: <5f865b62-4867-2c7b-715a-0605759e647f@redhat.com> > On Jan 23, 2020, at 3:39 PM, Waiman Long <longman@redhat.com> wrote: > > On 1/23/20 2:55 PM, Waiman Long wrote: >> Playing with lock event counts, I would like you to change the meaning >> intra_count parameter that you are tracking. Instead of tracking the >> number of times a lock is passed to a waiter of the same node >> consecutively, I would like you to track the number of times the head >> waiter in the secondary queue has given up its chance to acquire the >> lock because a later waiter has jumped the queue and acquire the lock >> before it. Isn’t that the same thing? Note that we keep track of the number of intra-node lock transfers only when the secondary queue is not empty. >> This value determines the worst case latency that a secondary >> queue waiter can experience. So > > Well, that is not strictly true as a a waiter in the middle of the > secondary queue can go back and fro between the queues for a number of > times. Of course, if we can ensure that when a FLUSH_SECONDARY_QUEUE is > issued, those waiters that were in the secondary queue won't be put back > into the secondary queue again. This will not work as intended when we have more than 2 nodes. That is, if we have threads from node A & B in the secondary queue, and then the queue is flushed and its head (say, from node A) gets the lock, we want to push threads from node B back into the secondary queue, to keep the lock on node A. And if we have only 2 nodes, a waiter in the middle of the secondary queue will never go back into the secondary queue, even if the threshold is small. This is because we flush the secondary queue by putting all its waiters in the front of the main queue, and the secondary queue will remain empty at least until we reach a thread from another node. Regards, — Alex _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-01-23 23:40 UTC|newest] Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-15 3:59 [PATCH v9 0/5] Add NUMA-awareness to qspinlock Alex Kogan 2020-01-15 3:59 ` Alex Kogan 2020-01-15 3:59 ` [PATCH v9 1/5] locking/qspinlock: Rename mcs lock/unlock macros and make them more generic Alex Kogan 2020-01-15 3:59 ` Alex Kogan 2020-01-15 3:59 ` [PATCH v9 2/5] locking/qspinlock: Refactor the qspinlock slow path Alex Kogan 2020-01-15 3:59 ` Alex Kogan 2020-01-15 3:59 ` Alex Kogan 2020-01-15 3:59 ` [PATCH v9 3/5] locking/qspinlock: Introduce CNA into the slow path of qspinlock Alex Kogan 2020-01-15 3:59 ` Alex Kogan 2020-01-15 3:59 ` Alex Kogan 2020-01-23 9:26 ` Peter Zijlstra 2020-01-23 9:26 ` Peter Zijlstra 2020-01-23 9:26 ` Peter Zijlstra 2020-01-23 10:06 ` Peter Zijlstra 2020-01-23 10:06 ` Peter Zijlstra 2020-01-23 10:06 ` Peter Zijlstra 2020-01-23 10:16 ` Peter Zijlstra 2020-01-23 10:16 ` Peter Zijlstra 2020-01-23 10:16 ` Peter Zijlstra 2020-01-23 11:22 ` Will Deacon 2020-01-23 11:22 ` Will Deacon 2020-01-23 13:17 ` Peter Zijlstra 2020-01-23 13:17 ` Peter Zijlstra 2020-01-23 13:17 ` Peter Zijlstra 2020-01-23 14:15 ` Waiman Long 2020-01-23 14:15 ` Waiman Long 2020-01-23 15:29 ` Peter Zijlstra 2020-01-23 15:29 ` Peter Zijlstra 2020-01-23 15:29 ` Peter Zijlstra 2020-01-15 3:59 ` [PATCH v9 4/5] locking/qspinlock: Introduce starvation avoidance into CNA Alex Kogan 2020-01-15 3:59 ` Alex Kogan 2020-01-23 19:55 ` Waiman Long 2020-01-23 19:55 ` Waiman Long 2020-01-23 20:39 ` Waiman Long 2020-01-23 20:39 ` Waiman Long 2020-01-23 23:39 ` Alex Kogan [this message] 2020-01-23 23:39 ` Alex Kogan 2020-01-15 3:59 ` [PATCH v9 5/5] locking/qspinlock: Introduce the shuffle reduction optimization " Alex Kogan 2020-01-15 3:59 ` Alex Kogan 2020-03-02 1:14 ` [locking/qspinlock] 7b6da71157: unixbench.score 8.4% improvement kernel test robot 2020-03-02 1:14 ` kernel test robot 2020-03-02 1:14 ` kernel test robot 2020-01-22 11:45 ` [PATCH v9 0/5] Add NUMA-awareness to qspinlock Lihao Liang 2020-01-22 11:45 ` Lihao Liang 2020-01-22 17:24 ` Waiman Long 2020-01-22 17:24 ` Waiman Long 2020-01-23 11:35 ` Will Deacon 2020-01-23 11:35 ` Will Deacon 2020-01-23 15:25 ` Waiman Long 2020-01-23 15:25 ` Waiman Long 2020-01-23 19:08 ` Waiman Long 2020-01-23 19:08 ` Waiman Long 2020-01-22 19:29 ` Alex Kogan 2020-01-22 19:29 ` Alex Kogan 2020-01-26 0:32 ` Lihao Liang 2020-01-26 0:32 ` Lihao Liang 2020-01-26 1:58 ` Lihao Liang 2020-01-26 1:58 ` Lihao Liang 2020-01-26 1:58 ` Lihao Liang 2020-01-27 16:01 ` Alex Kogan 2020-01-27 16:01 ` Alex Kogan 2020-01-29 1:39 ` Lihao Liang 2020-01-29 1:39 ` Lihao Liang 2020-01-27 6:16 ` Alex Kogan 2020-01-27 6:16 ` Alex Kogan 2020-01-24 22:24 ` Paul E. McKenney 2020-01-24 22:24 ` Paul E. McKenney [not found] ` <6AAE7FC6-F5DE-4067-8BC4-77F27948CD09@oracle.com> 2020-01-25 0:57 ` Paul E. McKenney 2020-01-25 0:57 ` Paul E. McKenney 2020-01-25 1:59 ` Waiman Long 2020-01-25 1:59 ` Waiman Long [not found] ` <adb4fb09-f374-4d64-096b-ba9ad8b35fd5@redhat.com> 2020-01-25 4:58 ` Paul E. McKenney 2020-01-25 4:58 ` Paul E. McKenney 2020-01-25 19:41 ` Waiman Long 2020-01-25 19:41 ` Waiman Long 2020-01-26 15:35 ` Paul E. McKenney 2020-01-26 15:35 ` Paul E. McKenney 2020-01-26 22:42 ` Paul E. McKenney 2020-01-26 22:42 ` Paul E. McKenney 2020-01-26 23:32 ` Paul E. McKenney 2020-01-26 23:32 ` Paul E. McKenney 2020-01-27 6:04 ` Alex Kogan 2020-01-27 6:04 ` Alex Kogan 2020-01-27 14:11 ` Waiman Long 2020-01-27 14:11 ` Waiman Long 2020-01-27 15:09 ` Paul E. McKenney 2020-01-27 15:09 ` Paul E. McKenney [not found] ` <9b3a3f16-5405-b6d1-d023-b85f4aab46dd@redhat.com> 2020-01-27 17:17 ` Waiman Long 2020-01-27 17:17 ` Waiman Long
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1B2B46E9-651E-4BA5-988A-924AE3E72C00@oracle.com \ --to=alex.kogan@oracle.com \ --cc=arnd@arndb.de \ --cc=bp@alien8.de \ --cc=daniel.m.jordan@oracle.com \ --cc=dave.dice@oracle.com \ --cc=guohanjun@huawei.com \ --cc=hpa@zytor.com \ --cc=jglauber@marvell.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=longman@redhat.com \ --cc=mingo@redhat.com \ --cc=peterz@infradead.org \ --cc=steven.sistare@oracle.com \ --cc=tglx@linutronix.de \ --cc=will.deacon@arm.com \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.