A plan of pushing ddsnap kernel patches to mainstream?

4 views
Skip to first unread message

Jiaying Zhang

unread,
May 9, 2008, 9:27:12 PM5/9/08
to Zumastor
A lot of people have asked if and when ddsnap patches will get into
linux kernel mainstream. So I think maybe we should have some kind
of plan on how to do that. We have talked about pushing ddsnap
patches into -mm kernel tree first. Maybe we can try to first push
the bio_throttling patch into -mm tree, then push the ddsnap patche into
-mm, then the bio_throttling into mainstream, and then the ddsnap patche
into mainstream. There are a couple of patches, like set_MEMALLOC
patch and NFS suspend patch, that we may push into mainstream
directly. And maybe we should start now.

Any opinions?

Jiaying

Daniel Phillips

unread,
May 10, 2008, 7:58:50 AM5/10/08
to zuma...@googlegroups.com, Jiaying Zhang

The NFS suspend patch is no great work of art, to say the least.
I suggest we post it to linux-nfs. I expect they will tell us a
better way to do it. But in the surprising event that the patch
actually does something that cannot be done any other way, they
might just take it as is. Or suggest how to modify it into an
interface along the lines of existing interfaces without changing
its basic function.

The patch we really need in mainline is bio-throttle. But we do
not need it in _before_ merging ddsnap, we can just make it part
of the ddsnap patch set. There is no reason our submission to -mm
needs to be an entirely self-contained module.

The biggest thing I don't like about ddsnap structurally is the
need to specify two sockets on the ddsnap start server command. I
think we ought to fix that before submitting.

I think the bio stacking patch set has the best chance of going
into mainline soonest because it provides an easy-to-measure benefit
without much disruption and (once I have completed the rewrite)
cleans up a section of Device Mapper with comments "BEGIN CRUFT ...
END CRUFT", without otherwise changing operation. Unfortunately,
this patch set is not actually needed for ddsnap. But still, it
would be a good start because it is pretty hard to criticize, it
reduces allocations and associated locking a lot.

Daniel

Jeff Schroeder

unread,
May 10, 2008, 3:53:19 PM5/10/08
to Daniel Phillips, zuma...@googlegroups.com, Jiaying Zhang
On Sat, May 10, 2008 at 4:58 AM, Daniel Phillips <phil...@phunq.net> wrote:
>
> On Friday 09 May 2008 18:27, Jiaying Zhang wrote:
>> A lot of people have asked if and when ddsnap patches will get into
>> linux kernel mainstream. So I think maybe we should have some kind
>> of plan on how to do that. We have talked about pushing ddsnap
>> patches into -mm kernel tree first. Maybe we can try to first push
>> the bio_throttling patch into -mm tree, then push the ddsnap patche into
>> -mm, then the bio_throttling into mainstream, and then the ddsnap patche
>> into mainstream. There are a couple of patches, like set_MEMALLOC
>> patch and NFS suspend patch, that we may push into mainstream
>> directly. And maybe we should start now.
>>
>> Any opinions?
>
> The NFS suspend patch is no great work of art, to say the least.
> I suggest we post it to linux-nfs. I expect they will tell us a
> better way to do it. But in the surprising event that the patch
> actually does something that cannot be done any other way, they
> might just take it as is. Or suggest how to modify it into an
> interface along the lines of existing interfaces without changing
> its basic function.
>
> The patch we really need in mainline is bio-throttle. But we do
> not need it in _before_ merging ddsnap, we can just make it part
> of the ddsnap patch set. There is no reason our submission to -mm
> needs to be an entirely self-contained module.

Didn't Jens, umm, have a few issues with the bio-throttle patches? It seems
like those would need to be addressed before that patch goes into -mm.
http://lkml.org/lkml/2007/12/5/346

Following recent kernel development, you might actually shoot for
getting in -next.
Andrew pulls from -next for -mm and wants everything in -next before
going to him.
He (andrew) has said this repeatedly.
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/

Also, were the printk patches I submitted forever ago ever merged? Those were
written to fix checkpatch cleanups to help you guys get ddsnap upstream. Has
anyone ran checkpatch on the ddsnap patches at all?

http://www.digitalprognosis.com/opensource/patches/zumastor/02-zumastor-dm-ddsnap.c-r959-change-printk-to-use-KERN-priorities-v2.patch

Lets do this 1 step at a time.

--
Jeff Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com

Daniel Phillips

unread,
May 10, 2008, 4:32:27 PM5/10/08
to jeffsc...@computer.org, zuma...@googlegroups.com, Jiaying Zhang
On Saturday 10 May 2008 12:53, Jeff Schroeder wrote:
> Didn't Jens, umm, have a few issues with the bio-throttle patches? It seems
> like those would need to be addressed before that patch goes into -mm.
> http://lkml.org/lkml/2007/12/5/346

He didn't like adding 4 bytes to struct bio, as I recall that was the
only substantive issue. He also found a bug, which was fixed. All
this needs is a bunch more time sunk in from me, to show everybody the
latest (debugged!) versions, explain the need again, and quantify with
measurements that the new field does not significantly affect memory
use or performance (my bio allocation patch saves significantly more
memory than bio-throttle costs, and alignment wastage wastes way more
memory than bio-throttle costs.

> Following recent kernel development, you might actually shoot for getting in -next.
> Andrew pulls from -next for -mm and wants everything in -next before going to him.
> He (andrew) has said this repeatedly.
> http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/

Right.

> Also, were the printk patches I submitted forever ago ever merged? Those were
> written to fix checkpatch cleanups to help you guys get ddsnap upstream.

Ahem, no, they fell through the cracks. I think "Ping early, ping often"
applies.

> Has anyone ran checkpatch on the ddsnap patches at all?

The kernel code has gotten scarcely any work at all, for many months. It
does need some lovin. The bright spot there is, it didn't need much work
to stay up and running.

Thanks Jeff, it looks good.

Hunk #6 FAILED at 1127.
Hunk #7 succeeded at 1259 (offset -51 lines).
Hunk #8 succeeded at 1267 (offset -51 lines).
Hunk #9 FAILED at 1548.
2 out of 9 hunks FAILED -- saving rejects to file dm-ddsnap.c.rej

Fixed and commited.

Daniel

Jiaying Zhang

unread,
May 12, 2008, 5:58:16 PM5/12/08
to Daniel Phillips, zuma...@googlegroups.com
Maybe we can try to push set_MEMALLOC patch and nfs suspend patch
into mainstream and push ddsnap patch into -mm or -next at the same time
you are working on getting bio stacking patch into mainstream.

Jiaying

Daniel Phillips

unread,
May 12, 2008, 6:53:53 PM5/12/08
to Jiaying Zhang, zuma...@googlegroups.com
On Monday 12 May 2008 14:58, Jiaying Zhang wrote:
> Maybe we can try to push set_MEMALLOC patch and nfs suspend patch
> into mainstream and push ddsnap patch into -mm or -next at the same time
> you are working on getting bio stacking patch into mainstream.

OK. How would you like to try submitting the first one to lkml and the
second one to linux-nfs? I will support you, help proofread the mail,
cheerlead the post, whatever you want.

It is about time that the LKML community started hearing something from
the up-and-coming Jiaying Zhang :-)

Daniel

Reply all
Reply to author
Forward
0 new messages