All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brown <david.brown@hesbynett.no>
To: Dan Williams <djbw@fb.com>
Cc: Kumar Sundararajan <kumar@fb.com>, NeilBrown <neilb@suse.de>,
	linux-raid <linux-raid@vger.kernel.org>
Subject: Re: [PATCH] raid5: add support for rmw writes in raid6
Date: Tue, 30 Apr 2013 08:48:29 +0200	[thread overview]
Message-ID: <517F693D.5020700@hesbynett.no> (raw)
In-Reply-To: <CAA9_cme5Atj2y7aetaRDfiyaBERk-rWCOkw5k7=9YrgcKzYc7w@mail.gmail.com>

On 30/04/13 02:05, Dan Williams wrote:
> On Mon, Apr 29, 2013 at 12:28 PM, David Brown <david.brown@hesbynett.no> wrote:
>> For each data block you are changing, you will need to remove the old g^i *
>> Di_old then add in the new g^i * Di_new, so you can still use this
>> simplification to reduce the number of multiplies.  If you want to change
>> blocks "i" and "j", you thus do:
>>
>> Q_new = Q_old + g^i * (Di_old + Di_new) + g^j * (Dj_old + Dj_new)
>>
>> But as I say, I only know the maths - not the code.
> 
> The issue is where to store those intermediate Di_old + Di_new results
> without doubling the size of the stripe cache.
> 

(As before, I haven't looked at the code.  I justify my laziness by
claiming that I might come up with fresh ideas without how to implement
things.  But only you folks can say what takes more work, and what is
riskier in the code.)

I don't see that you would need to double the size of the stripe cache.
 You might need an extra few block spaces, but not double the cache.

Also, once you have done this calculation (assuming you did the easy
P_new first), you no longer need to keep Di_old lying around - it's
going to be replaced with the new stripe data.  So maybe you can do the
operation as "Di_old += Di_new" - i.e., in place and without using more
memory.  That is going to be faster too, as it is more cache friendly.
On the other hand, it might involve more locking or other tracking
mechanisms to avoid problems if something else is trying to access the
same caches.


  reply	other threads:[~2013-04-30  6:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-18  0:56 [PATCH] raid5: add support for rmw writes in raid6 Dan Williams
2013-04-18 18:40 ` Dan Williams
2013-04-22  4:22 ` NeilBrown
2013-04-26 21:35   ` Dan Williams
2013-04-29  1:29     ` NeilBrown
2013-04-29  7:10       ` David Brown
2013-04-29 16:11         ` Kumar Sundararajan
2013-04-29 19:28           ` David Brown
2013-04-30  0:05             ` Dan Williams
2013-04-30  6:48               ` David Brown [this message]
2013-04-30 16:01                 ` Kumar Sundararajan
2013-04-30 16:10                   ` Kumar Sundararajan
2013-04-30 18:39                     ` David Brown
2013-04-29 17:54       ` Kumar Sundararajan
2013-04-30 21:32       ` Dan Williams
2013-05-01 13:57         ` David Brown
2013-05-08 17:42       ` Dan Williams

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=517F693D.5020700@hesbynett.no \
    --to=david.brown@hesbynett.no \
    --cc=djbw@fb.com \
    --cc=kumar@fb.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /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.