From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Colin Pitrat <colin.pitrat@gmail.com>
Cc: perfbook@vger.kernel.org
Subject: Re: Approximate structure-allocation limit problem improvement
Date: Fri, 18 Dec 2015 10:03:46 -0800 [thread overview]
Message-ID: <20151218180346.GQ4054@linux.vnet.ibm.com> (raw)
In-Reply-To: <CABy3NjQQF+Kr+9MYmWVHY=b-d=NdOjTpiHMaKhuZzBECyDzOCA@mail.gmail.com>
On Wed, Dec 16, 2015 at 02:21:45PM +0100, Colin Pitrat wrote:
> Hello,
>
> in chapter 5 (Counting), in the paragraph concerning "Approximate
> structure-allocation limit problem", it is said:
>
> "Similarly, sub_count() can fail even when the aggregate value of the
> counter is nowhere near zero. In many cases, this is unacceptable."
>
> In the case of the Quick Quiz 5.3 question, it's true that it's quite
> a problem if it means freeing the structure fails because the counter
> cannot be updated ! And freeing it without updating the counter means
> the counter shifts from reality.
>
> However, the very existence of the structure is a guarantee that the
> real (total) counter value cannot be 0 or less than delta, so couldn't
> we imagine to always succeed the sub_count operation by keeping a
> global negative offset ? In the slow path, after globalize_count, if
> the global count is lower than delta then we set it to 0 and we
> increment the negative offset by what remains.
>
> On the next slow path operation during a add_count, this negative
> offset can be removed (or reduced) by reducing the local counter of
> the thread by the same value.
>
> This improvement over the proposed solution make it an acceptable
> answer for the quick quiz 5.3 whereas it isn't without.
>
> What do you think ?
> Should I spend a bit of time writing a paragraph and a code sample about it ?
I must confess that I have read this message a few times, and still don't
understand what you are getting at. Part of my trouble is that I am
not sure why you are comparing against zero -- the structure-allocation
problem only needs to compare against the limit. But you might mean
zero after offset, or you might be talking about some related problem.
So perhaps a paragraph and sample code would help me understand the
problem you are looking at and your example solution.
Thanx, Paul
next prev parent reply other threads:[~2015-12-18 18:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 13:21 Approximate structure-allocation limit problem improvement Colin Pitrat
2015-12-18 18:03 ` Paul E. McKenney [this message]
2015-12-21 15:18 ` Colin Pitrat
2015-12-21 15:28 ` Paul E. McKenney
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=20151218180346.GQ4054@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=colin.pitrat@gmail.com \
--cc=perfbook@vger.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: link
Be 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.