* Re: Bcache v. whatever
2013-01-14 22:32 Bcache v. whatever Kent Overstreet
@ 2013-01-15 1:49 ` Greg KH
2013-01-15 21:18 ` Kent Overstreet
2013-01-15 9:20 ` James Bottomley
` (5 subsequent siblings)
6 siblings, 1 reply; 21+ messages in thread
From: Greg KH @ 2013-01-15 1:49 UTC (permalink / raw)
To: Kent Overstreet
Cc: linux-kernel, linux-bcache, akpm, tj, axboe, James.Bottomley, snitzer
On Mon, Jan 14, 2013 at 02:32:02PM -0800, Kent Overstreet wrote:
> Bcache: a block layer SSD cache
>
> Does writethrough and writeback, handles unclean shutdown, and has
> various other nifty features. See the wiki and the documentation for
> more:
>
> http://bcache.evilpiepirate.org
>
> Over the Christmas break I finally got the tree into a self contained
> state that ought to be suitable for merging; this tree is fairly close
> to the previous stable tree that people have been running on production
> servers for awhile (and that I've been running on this workstation),
>
> So, I think this is ready for mainline and I'd like to get it in. I
> should've tried to push it ages ago, but I was hoping to get in various
> block layer cleanups first; I finally deided to work around them in the
> meantime since I haven't had time to finish the block layer stuff.
>
> Not everything has been addressed since I last posted for review
> feedback - notably the closure code was controversial and for now I've
> just moved that into drivers/block/bcache (though I've been refactoring
> stuff to make it less asynchronous lately; most of that work is in the
> testing/dev branches). The bigger issue IMO is the userspace interface -
> I'd like to finish the md integration so it doesn't need userspace stuff
> for probing/bootup. So, I'd be fine with it going into staging if that's
> the consensus, but it's stable tested code.
If it goes into staging, I need a reason why it can't be merged into the
"real" part of the kernel, and what will be done to get it there.
Oh, and you will need to get acks from the people who's symbols you are
wanting to export, usually staging patches are self-contained.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Bcache v. whatever
2013-01-15 1:49 ` Greg KH
@ 2013-01-15 21:18 ` Kent Overstreet
2013-01-15 22:50 ` Greg KH
0 siblings, 1 reply; 21+ messages in thread
From: Kent Overstreet @ 2013-01-15 21:18 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel, linux-bcache, akpm, tj, axboe, James.Bottomley, snitzer
On Mon, Jan 14, 2013 at 05:49:31PM -0800, Greg KH wrote:
> On Mon, Jan 14, 2013 at 02:32:02PM -0800, Kent Overstreet wrote:
> > Bcache: a block layer SSD cache
> >
> > Does writethrough and writeback, handles unclean shutdown, and has
> > various other nifty features. See the wiki and the documentation for
> > more:
> >
> > http://bcache.evilpiepirate.org
> >
> > Over the Christmas break I finally got the tree into a self contained
> > state that ought to be suitable for merging; this tree is fairly close
> > to the previous stable tree that people have been running on production
> > servers for awhile (and that I've been running on this workstation),
> >
> > So, I think this is ready for mainline and I'd like to get it in. I
> > should've tried to push it ages ago, but I was hoping to get in various
> > block layer cleanups first; I finally deided to work around them in the
> > meantime since I haven't had time to finish the block layer stuff.
> >
> > Not everything has been addressed since I last posted for review
> > feedback - notably the closure code was controversial and for now I've
> > just moved that into drivers/block/bcache (though I've been refactoring
> > stuff to make it less asynchronous lately; most of that work is in the
> > testing/dev branches). The bigger issue IMO is the userspace interface -
> > I'd like to finish the md integration so it doesn't need userspace stuff
> > for probing/bootup. So, I'd be fine with it going into staging if that's
> > the consensus, but it's stable tested code.
>
> If it goes into staging, I need a reason why it can't be merged into the
> "real" part of the kernel, and what will be done to get it there.
I don't personally see why it can't, but maybe other people will chime
in. There's certainly still stuff to do (something this size is never
finished) but I'm not abandoning the code.
> Oh, and you will need to get acks from the people who's symbols you are
> wanting to export, usually staging patches are self-contained.
Yeah, good point. I'll mail out those patches now.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bcache v. whatever
2013-01-15 21:18 ` Kent Overstreet
@ 2013-01-15 22:50 ` Greg KH
0 siblings, 0 replies; 21+ messages in thread
From: Greg KH @ 2013-01-15 22:50 UTC (permalink / raw)
To: Kent Overstreet
Cc: linux-kernel, linux-bcache, akpm, tj, axboe, James.Bottomley, snitzer
On Tue, Jan 15, 2013 at 01:18:37PM -0800, Kent Overstreet wrote:
> On Mon, Jan 14, 2013 at 05:49:31PM -0800, Greg KH wrote:
> > On Mon, Jan 14, 2013 at 02:32:02PM -0800, Kent Overstreet wrote:
> > > Bcache: a block layer SSD cache
> > >
> > > Does writethrough and writeback, handles unclean shutdown, and has
> > > various other nifty features. See the wiki and the documentation for
> > > more:
> > >
> > > http://bcache.evilpiepirate.org
> > >
> > > Over the Christmas break I finally got the tree into a self contained
> > > state that ought to be suitable for merging; this tree is fairly close
> > > to the previous stable tree that people have been running on production
> > > servers for awhile (and that I've been running on this workstation),
> > >
> > > So, I think this is ready for mainline and I'd like to get it in. I
> > > should've tried to push it ages ago, but I was hoping to get in various
> > > block layer cleanups first; I finally deided to work around them in the
> > > meantime since I haven't had time to finish the block layer stuff.
> > >
> > > Not everything has been addressed since I last posted for review
> > > feedback - notably the closure code was controversial and for now I've
> > > just moved that into drivers/block/bcache (though I've been refactoring
> > > stuff to make it less asynchronous lately; most of that work is in the
> > > testing/dev branches). The bigger issue IMO is the userspace interface -
> > > I'd like to finish the md integration so it doesn't need userspace stuff
> > > for probing/bootup. So, I'd be fine with it going into staging if that's
> > > the consensus, but it's stable tested code.
> >
> > If it goes into staging, I need a reason why it can't be merged into the
> > "real" part of the kernel, and what will be done to get it there.
>
> I don't personally see why it can't, but maybe other people will chime
> in. There's certainly still stuff to do (something this size is never
> finished) but I'm not abandoning the code.
Ok, then it should be accepted, care to make it up into a format that
can be applied to someone's tree? We can't do anything in the current
git-tree format it is in today.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bcache v. whatever
2013-01-14 22:32 Bcache v. whatever Kent Overstreet
2013-01-15 1:49 ` Greg KH
@ 2013-01-15 9:20 ` James Bottomley
2013-01-15 20:59 ` Kent Overstreet
2013-01-15 21:25 ` [PATCH 1/4] Revert "rw_semaphore: remove up/down_read_non_owner" Kent Overstreet
` (4 subsequent siblings)
6 siblings, 1 reply; 21+ messages in thread
From: James Bottomley @ 2013-01-15 9:20 UTC (permalink / raw)
To: Kent Overstreet; +Cc: linux-kernel, linux-bcache, akpm, tj, axboe, snitzer
On Mon, 2013-01-14 at 14:32 -0800, Kent Overstreet wrote:
> Bcache: a block layer SSD cache
>
> Does writethrough and writeback, handles unclean shutdown, and has
> various other nifty features. See the wiki and the documentation for
> more:
>
> http://bcache.evilpiepirate.org
>
> Over the Christmas break I finally got the tree into a self contained
> state that ought to be suitable for merging; this tree is fairly close
> to the previous stable tree that people have been running on production
> servers for awhile (and that I've been running on this workstation),
>
> So, I think this is ready for mainline and I'd like to get it in. I
> should've tried to push it ages ago, but I was hoping to get in various
> block layer cleanups first; I finally deided to work around them in the
> meantime since I haven't had time to finish the block layer stuff.
>
> Not everything has been addressed since I last posted for review
> feedback - notably the closure code was controversial and for now I've
> just moved that into drivers/block/bcache (though I've been refactoring
> stuff to make it less asynchronous lately; most of that work is in the
> testing/dev branches). The bigger issue IMO is the userspace interface -
> I'd like to finish the md integration so it doesn't need userspace stuff
> for probing/bootup. So, I'd be fine with it going into staging if that's
> the consensus, but it's stable tested code.
>
> The code is available at
> http://evilpiepirate.org/git/linux-bcache.git bcache-for-upstream
>
> This latest branch is on top of v3.8-rc3:
The guy to merge this is the maintainer in that layer, which is Alasdair
Kergon. I know you've been sending patches to the dm-devel list, what's
the reason you didn't include him in the cc list? Is there some type of
political problem in dm? From reading the list, it looks like your
patches are being tested and progressing, so what am I missing?
James
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Bcache v. whatever
2013-01-15 9:20 ` James Bottomley
@ 2013-01-15 20:59 ` Kent Overstreet
2013-01-15 23:15 ` James Bottomley
0 siblings, 1 reply; 21+ messages in thread
From: Kent Overstreet @ 2013-01-15 20:59 UTC (permalink / raw)
To: James Bottomley
Cc: linux-kernel, linux-bcache, akpm, tj, axboe, snitzer, agk, neilb
On Tue, Jan 15, 2013 at 09:20:56AM +0000, James Bottomley wrote:
> On Mon, 2013-01-14 at 14:32 -0800, Kent Overstreet wrote:
> > Bcache: a block layer SSD cache
> >
> > Does writethrough and writeback, handles unclean shutdown, and has
> > various other nifty features. See the wiki and the documentation for
> > more:
> >
> > http://bcache.evilpiepirate.org
> >
> > Over the Christmas break I finally got the tree into a self contained
> > state that ought to be suitable for merging; this tree is fairly close
> > to the previous stable tree that people have been running on production
> > servers for awhile (and that I've been running on this workstation),
> >
> > So, I think this is ready for mainline and I'd like to get it in. I
> > should've tried to push it ages ago, but I was hoping to get in various
> > block layer cleanups first; I finally deided to work around them in the
> > meantime since I haven't had time to finish the block layer stuff.
> >
> > Not everything has been addressed since I last posted for review
> > feedback - notably the closure code was controversial and for now I've
> > just moved that into drivers/block/bcache (though I've been refactoring
> > stuff to make it less asynchronous lately; most of that work is in the
> > testing/dev branches). The bigger issue IMO is the userspace interface -
> > I'd like to finish the md integration so it doesn't need userspace stuff
> > for probing/bootup. So, I'd be fine with it going into staging if that's
> > the consensus, but it's stable tested code.
> >
> > The code is available at
> > http://evilpiepirate.org/git/linux-bcache.git bcache-for-upstream
> >
> > This latest branch is on top of v3.8-rc3:
>
> The guy to merge this is the maintainer in that layer, which is Alasdair
> Kergon. I know you've been sending patches to the dm-devel list, what's
> the reason you didn't include him in the cc list? Is there some type of
> political problem in dm? From reading the list, it looks like your
> patches are being tested and progressing, so what am I missing?
That was merely an oversight - but, bcache is currently just another
block device, it doesn't plug into dm or md. There was some md
integration work started, and that's the one I'm more inclined to work
on personally (if and when I find the time).
So I'm not sure why it'd go in via dm, it seems to me it'd make just as
much sense for it to go in via Neil Brown's tree. Unless there's
something I'm missing?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bcache v. whatever
2013-01-15 20:59 ` Kent Overstreet
@ 2013-01-15 23:15 ` James Bottomley
2013-01-15 23:33 ` Kent Overstreet
0 siblings, 1 reply; 21+ messages in thread
From: James Bottomley @ 2013-01-15 23:15 UTC (permalink / raw)
To: Kent Overstreet
Cc: linux-kernel, linux-bcache, akpm, tj, axboe, snitzer, agk, neilb
On Tue, 2013-01-15 at 12:59 -0800, Kent Overstreet wrote:
> On Tue, Jan 15, 2013 at 09:20:56AM +0000, James Bottomley wrote:
> > On Mon, 2013-01-14 at 14:32 -0800, Kent Overstreet wrote:
> > > Bcache: a block layer SSD cache
> > >
> > > Does writethrough and writeback, handles unclean shutdown, and has
> > > various other nifty features. See the wiki and the documentation for
> > > more:
> > >
> > > http://bcache.evilpiepirate.org
> > >
> > > Over the Christmas break I finally got the tree into a self contained
> > > state that ought to be suitable for merging; this tree is fairly close
> > > to the previous stable tree that people have been running on production
> > > servers for awhile (and that I've been running on this workstation),
> > >
> > > So, I think this is ready for mainline and I'd like to get it in. I
> > > should've tried to push it ages ago, but I was hoping to get in various
> > > block layer cleanups first; I finally deided to work around them in the
> > > meantime since I haven't had time to finish the block layer stuff.
> > >
> > > Not everything has been addressed since I last posted for review
> > > feedback - notably the closure code was controversial and for now I've
> > > just moved that into drivers/block/bcache (though I've been refactoring
> > > stuff to make it less asynchronous lately; most of that work is in the
> > > testing/dev branches). The bigger issue IMO is the userspace interface -
> > > I'd like to finish the md integration so it doesn't need userspace stuff
> > > for probing/bootup. So, I'd be fine with it going into staging if that's
> > > the consensus, but it's stable tested code.
> > >
> > > The code is available at
> > > http://evilpiepirate.org/git/linux-bcache.git bcache-for-upstream
> > >
> > > This latest branch is on top of v3.8-rc3:
> >
> > The guy to merge this is the maintainer in that layer, which is Alasdair
> > Kergon. I know you've been sending patches to the dm-devel list, what's
> > the reason you didn't include him in the cc list? Is there some type of
> > political problem in dm? From reading the list, it looks like your
> > patches are being tested and progressing, so what am I missing?
>
> That was merely an oversight - but, bcache is currently just another
> block device, it doesn't plug into dm or md. There was some md
> integration work started, and that's the one I'm more inclined to work
> on personally (if and when I find the time).
I think md integration would be a bit of a mistake, since md is pretty
much only a raid engine at this point in time. There are also a couple
of other dm cache targets, so it would be nice to have one rather than
three. This all, however, seems to be under discussion on the dm list.
> So I'm not sure why it'd go in via dm, it seems to me it'd make just as
> much sense for it to go in via Neil Brown's tree. Unless there's
> something I'm missing?
Um, well there's no caching patches in the md tree; it's RAID only. The
basic caching stuff is all in the dm tree, which is why it's the natural
one.
It seems to me that your stuff is progressing on the dm list, so I don't
really see a need to circumvent the process in the dm tree ... unless
there's some problem I'm not seeing?
James
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bcache v. whatever
2013-01-15 23:15 ` James Bottomley
@ 2013-01-15 23:33 ` Kent Overstreet
2013-01-16 1:29 ` Alasdair G Kergon
0 siblings, 1 reply; 21+ messages in thread
From: Kent Overstreet @ 2013-01-15 23:33 UTC (permalink / raw)
To: James Bottomley
Cc: linux-kernel, linux-bcache, akpm, tj, axboe, snitzer, agk, neilb
On Tue, Jan 15, 2013 at 11:15:38PM +0000, James Bottomley wrote:
> I think md integration would be a bit of a mistake, since md is pretty
> much only a raid engine at this point in time. There are also a couple
> of other dm cache targets, so it would be nice to have one rather than
> three. This all, however, seems to be under discussion on the dm list.
The raid vs. caching bit is a bit beside the point IMO; they both
aggregate block devices and expose virtual block devices, and the
mechanism for doing so isn't part of the generic framework.
I'm not morally opposed to dm integration, I'm just more comfortable
with the md code and find it easier to understand and work with.
And the goal I care about is just commonality of userspace interfaces
and tooling, which integration with either would accomplish.
> > So I'm not sure why it'd go in via dm, it seems to me it'd make just as
> > much sense for it to go in via Neil Brown's tree. Unless there's
> > something I'm missing?
>
> Um, well there's no caching patches in the md tree; it's RAID only. The
> basic caching stuff is all in the dm tree, which is why it's the natural
> one.
>
> It seems to me that your stuff is progressing on the dm list, so I don't
> really see a need to circumvent the process in the dm tree ... unless
> there's some problem I'm not seeing?
I haven't been active on dm-devel, besides the occasional cross
posting... not sure what activity you're referring to on the dm list,
But if Alasdair wants to pick it up I'm not complaining, I don't
particularly care who merges it.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bcache v. whatever
2013-01-15 23:33 ` Kent Overstreet
@ 2013-01-16 1:29 ` Alasdair G Kergon
2013-01-17 23:43 ` Mike Snitzer
0 siblings, 1 reply; 21+ messages in thread
From: Alasdair G Kergon @ 2013-01-16 1:29 UTC (permalink / raw)
To: Kent Overstreet
Cc: James Bottomley, linux-kernel, linux-bcache, akpm, tj, axboe,
snitzer, agk, neilb
On Tue, Jan 15, 2013 at 03:33:47PM -0800, Kent Overstreet wrote:
> I haven't been active on dm-devel, besides the occasional cross
> posting... not sure what activity you're referring to on the dm list,
A caching framework based on dm has been proposed by Joe Thornber (the
original author of dm).
Mike Snitzer is trying to adapt the performance tests for this dm-based
framework to include the latest bcache code that you just posted to
start to give us an idea of the circumstances in which each of them work
well (or badly).
1, Caching is a complicated feature: It's easy to get no benefit or even
a negative benefit from a cache if you use an inappropriate policy or
don't tune it to your I/O patterns.
2. We now have several independent/overlapping implementations of this
type of caching. Comparing and contrasting them should help us to tease
out the critical design elements and optimisations and decide which of
them together or separately (or some hybrid) would enable the kernel to
support the widest range of situations users require with the minimum
of code and complexity.
3. We all want to move quickly now, perhaps even with something in the
next merge window if we can or otherwise the one after that.
Alasdair
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bcache v. whatever
2013-01-16 1:29 ` Alasdair G Kergon
@ 2013-01-17 23:43 ` Mike Snitzer
0 siblings, 0 replies; 21+ messages in thread
From: Mike Snitzer @ 2013-01-17 23:43 UTC (permalink / raw)
To: Kent Overstreet, James Bottomley, linux-kernel, linux-bcache,
akpm, tj, axboe, agk, neilb
On Tue, Jan 15 2013 at 8:29pm -0500,
Alasdair G Kergon <agk@redhat.com> wrote:
> On Tue, Jan 15, 2013 at 03:33:47PM -0800, Kent Overstreet wrote:
> > I haven't been active on dm-devel, besides the occasional cross
> > posting... not sure what activity you're referring to on the dm list,
>
> A caching framework based on dm has been proposed by Joe Thornber (the
> original author of dm).
>
> Mike Snitzer is trying to adapt the performance tests for this dm-based
> framework to include the latest bcache code that you just posted to
> start to give us an idea of the circumstances in which each of them work
> well (or badly).
Unfortunately, the first automated test in the thinp-test-suite that I
ported to work with Bcache fails, here is a shell script that reproduces
the problem (having bcache use a small SSD is key to reproducing):
## /dev/spindle/data is a 16G linear LV on a SAS spindle
## /dev/stec/256m_lv is a 256M linear LV on a PCI-e SSD
## (larger SSD volume doesn't have this problem; because the working set fits better?)
make-bcache -B /dev/spindle/data -C /dev/stec/256m_lv --cache_replacement_policy=fifo -w 4096 --writeback --discard
echo /dev/spindle/data > /sys/fs/bcache/register
echo /dev/stec/256m_lv > /sys/fs/bcache/register
DM_DEV_NAME=$(basename `readlink /dev/mapper/spindle-data`)
BCACHE_DEV=$(basename `readlink /sys/block/${DM_DEV_NAME}/bcache/dev`)
mkfs.ext4 -E lazy_itable_init=1 /dev/${BCACHE_DEV}
mkdir ./kernel_builds
mount /dev/${BCACHE_DEV} ./kernel_builds -o discard
cd ./kernel_builds
## /root/linux-github is a local clone of linus' git repo
git clone /root/linux-github linux
cd linux
git checkout v2.6.12
sync
echo 3 > /proc/sys/vm/drop_caches
The drop_caches hangs (sh spins eating cpu), and ./kernel_builds cannot
be unmounted:
# ps auwwx | grep spin_bcache
root 18148 98.4 0.0 106208 1320 pts/2 R+ 17:42 49:39 /bin/sh /root/bin/spin_bcache
spin_bcache R running task 0 18148 4886 0x00000000
00000000154d154d 0000000000000000 ffff8802edc00d90 ffff88032d395e48
0000000000000001 ffffffffffffff10 0000000000000018 ffff8802f9802800
ffff88032d395d28 ffffffff8116b8d5 ffff88032de6f000 ffff880332682800
Call Trace:
[<ffffffff814f67e2>] ? _raw_spin_lock+0x12/0x30
[<ffffffff8116b8d5>] ? put_super+0x25/0x40
[<ffffffff8116ba65>] ? grab_super_passive+0x25/0xa0
[<ffffffff8116bb3f>] ? prune_super+0x5f/0x1a0
[<ffffffff8111d131>] ? shrink_slab+0xa1/0x2c0
[<ffffffff8111d096>] ? shrink_slab+0x6/0x2c0
[<ffffffff81194b22>] ? drop_caches_sysctl_handler+0x62/0x90
[<ffffffff811d7f56>] ? proc_sys_call_handler+0x96/0xd0
[<ffffffff811d7fa4>] ? proc_sys_write+0x14/0x20
[<ffffffff81169194>] ? vfs_write+0xb4/0x130
[<ffffffff8116993f>] ? sys_write+0x5f/0xa0
[<ffffffff814ff119>] ? system_call_fastpath+0x16/0x1b
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH 1/4] Revert "rw_semaphore: remove up/down_read_non_owner"
2013-01-14 22:32 Bcache v. whatever Kent Overstreet
2013-01-15 1:49 ` Greg KH
2013-01-15 9:20 ` James Bottomley
@ 2013-01-15 21:25 ` Kent Overstreet
2013-01-15 21:25 ` [PATCH 2/4] Export get_random_int() Kent Overstreet
` (3 subsequent siblings)
6 siblings, 0 replies; 21+ messages in thread
From: Kent Overstreet @ 2013-01-15 21:25 UTC (permalink / raw)
To: linux-kernel, linux-bcache
Cc: Kent Overstreet, Christoph Hellwig, David Howells
This reverts commit 11b80f459adaf91a712f95e7734a17655a36bf30.
Bcache needs rw semaphores for cache coherency in writeback mode -
writes have to take a read lock on a per cache device rw sem, and
release it when the bio completes.
But since this is for bios it's naturally not in the context of the
process that originally took the lock.
Signed-off-by: Kent Overstreet <koverstreet@google.com>
CC: Christoph Hellwig <hch@infradead.org>
CC: David Howells <dhowells@redhat.com>
---
include/linux/rwsem.h | 10 ++++++++++
kernel/rwsem.c | 16 ++++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
index 54bd7cd..ddfe46d 100644
--- a/include/linux/rwsem.h
+++ b/include/linux/rwsem.h
@@ -125,9 +125,19 @@ extern void downgrade_write(struct rw_semaphore *sem);
*/
extern void down_read_nested(struct rw_semaphore *sem, int subclass);
extern void down_write_nested(struct rw_semaphore *sem, int subclass);
+/*
+ * Take/release a lock when not the owner will release it.
+ *
+ * [ This API should be avoided as much as possible - the
+ * proper abstraction for this case is completions. ]
+ */
+extern void down_read_non_owner(struct rw_semaphore *sem);
+extern void up_read_non_owner(struct rw_semaphore *sem);
#else
# define down_read_nested(sem, subclass) down_read(sem)
# define down_write_nested(sem, subclass) down_write(sem)
+# define down_read_non_owner(sem) down_read(sem)
+# define up_read_non_owner(sem) up_read(sem)
#endif
#endif /* _LINUX_RWSEM_H */
diff --git a/kernel/rwsem.c b/kernel/rwsem.c
index 6850f53..78b7915 100644
--- a/kernel/rwsem.c
+++ b/kernel/rwsem.c
@@ -116,6 +116,15 @@ void down_read_nested(struct rw_semaphore *sem, int subclass)
EXPORT_SYMBOL(down_read_nested);
+void down_read_non_owner(struct rw_semaphore *sem)
+{
+ might_sleep();
+
+ __down_read(sem);
+}
+
+EXPORT_SYMBOL(down_read_non_owner);
+
void down_write_nested(struct rw_semaphore *sem, int subclass)
{
might_sleep();
@@ -126,6 +135,13 @@ void down_write_nested(struct rw_semaphore *sem, int subclass)
EXPORT_SYMBOL(down_write_nested);
+void up_read_non_owner(struct rw_semaphore *sem)
+{
+ __up_read(sem);
+}
+
+EXPORT_SYMBOL(up_read_non_owner);
+
#endif
--
1.7.12
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 2/4] Export get_random_int()
2013-01-14 22:32 Bcache v. whatever Kent Overstreet
` (2 preceding siblings ...)
2013-01-15 21:25 ` [PATCH 1/4] Revert "rw_semaphore: remove up/down_read_non_owner" Kent Overstreet
@ 2013-01-15 21:25 ` Kent Overstreet
2013-01-15 21:25 ` [PATCH 3/4] Export blk_fill_rwbs() Kent Overstreet
` (2 subsequent siblings)
6 siblings, 0 replies; 21+ messages in thread
From: Kent Overstreet @ 2013-01-15 21:25 UTC (permalink / raw)
To: linux-kernel, linux-bcache; +Cc: Kent Overstreet, Theodore Ts'o
Needed for bcache - need a cheap source of random numbers for perturbing
IO sizes, for rate limiting IO to the SSD.
Signed-off-by: Kent Overstreet <koverstreet@google.com>
CC: "Theodore Ts'o" <tytso@mit.edu>
---
drivers/char/random.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 85e81ec..d6f673e 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1481,6 +1481,7 @@ unsigned int get_random_int(void)
return ret;
}
+EXPORT_SYMBOL(get_random_int);
/*
* randomize_range() returns a start address such that
--
1.7.12
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 3/4] Export blk_fill_rwbs()
2013-01-14 22:32 Bcache v. whatever Kent Overstreet
` (3 preceding siblings ...)
2013-01-15 21:25 ` [PATCH 2/4] Export get_random_int() Kent Overstreet
@ 2013-01-15 21:25 ` Kent Overstreet
2013-02-01 3:48 ` Steven Rostedt
2013-01-15 21:25 ` [PATCH 4/4] Export __lockdep_no_validate__ Kent Overstreet
2013-04-25 23:17 ` Bcache v. whatever Andrew Morton
6 siblings, 1 reply; 21+ messages in thread
From: Kent Overstreet @ 2013-01-15 21:25 UTC (permalink / raw)
To: linux-kernel, linux-bcache
Cc: Kent Overstreet, Steven Rostedt, Frederic Weisbecker, Ingo Molnar
Exported so it can be used by bcache's tracepoints
Signed-off-by: Kent Overstreet <koverstreet@google.com>
CC: Steven Rostedt <rostedt@goodmis.org>
CC: Frederic Weisbecker <fweisbec@gmail.com>
CC: Ingo Molnar <mingo@redhat.com>
---
kernel/trace/blktrace.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
index c0bd030..dbe1667 100644
--- a/kernel/trace/blktrace.c
+++ b/kernel/trace/blktrace.c
@@ -1806,6 +1806,7 @@ void blk_fill_rwbs(char *rwbs, u32 rw, int bytes)
rwbs[i] = '\0';
}
+EXPORT_SYMBOL_GPL(blk_fill_rwbs);
#endif /* CONFIG_EVENT_TRACING */
--
1.7.12
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCH 3/4] Export blk_fill_rwbs()
2013-01-15 21:25 ` [PATCH 3/4] Export blk_fill_rwbs() Kent Overstreet
@ 2013-02-01 3:48 ` Steven Rostedt
2013-02-01 3:57 ` Li Zefan
0 siblings, 1 reply; 21+ messages in thread
From: Steven Rostedt @ 2013-02-01 3:48 UTC (permalink / raw)
To: Kent Overstreet, Li Zefan
Cc: linux-kernel, linux-bcache, Frederic Weisbecker, Ingo Molnar
Li,
Can you give an Ack or Nack for this.
Thanks,
-- Steve
On Tue, 2013-01-15 at 13:25 -0800, Kent Overstreet wrote:
> Exported so it can be used by bcache's tracepoints
>
> Signed-off-by: Kent Overstreet <koverstreet@google.com>
> CC: Steven Rostedt <rostedt@goodmis.org>
> CC: Frederic Weisbecker <fweisbec@gmail.com>
> CC: Ingo Molnar <mingo@redhat.com>
> ---
> kernel/trace/blktrace.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
> index c0bd030..dbe1667 100644
> --- a/kernel/trace/blktrace.c
> +++ b/kernel/trace/blktrace.c
> @@ -1806,6 +1806,7 @@ void blk_fill_rwbs(char *rwbs, u32 rw, int bytes)
>
> rwbs[i] = '\0';
> }
> +EXPORT_SYMBOL_GPL(blk_fill_rwbs);
>
> #endif /* CONFIG_EVENT_TRACING */
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 3/4] Export blk_fill_rwbs()
2013-02-01 3:48 ` Steven Rostedt
@ 2013-02-01 3:57 ` Li Zefan
2013-02-01 4:06 ` Steven Rostedt
0 siblings, 1 reply; 21+ messages in thread
From: Li Zefan @ 2013-02-01 3:57 UTC (permalink / raw)
To: Steven Rostedt
Cc: Kent Overstreet, linux-kernel, linux-bcache, Frederic Weisbecker,
Ingo Molnar
on 2013/2/1 11:48, Steven Rostedt wrote:
> Li,
>
> Can you give an Ack or Nack for this.
>
I think this patch shouldn't go into upstream without bcache code. We don't
export symbols for out of tree code.
> Thanks,
>
> -- Steve
>
>
> On Tue, 2013-01-15 at 13:25 -0800, Kent Overstreet wrote:
>> Exported so it can be used by bcache's tracepoints
>>
>> Signed-off-by: Kent Overstreet <koverstreet@google.com>
>> CC: Steven Rostedt <rostedt@goodmis.org>
>> CC: Frederic Weisbecker <fweisbec@gmail.com>
>> CC: Ingo Molnar <mingo@redhat.com>
>> ---
>> kernel/trace/blktrace.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
>> index c0bd030..dbe1667 100644
>> --- a/kernel/trace/blktrace.c
>> +++ b/kernel/trace/blktrace.c
>> @@ -1806,6 +1806,7 @@ void blk_fill_rwbs(char *rwbs, u32 rw, int bytes)
>>
>> rwbs[i] = '\0';
>> }
>> +EXPORT_SYMBOL_GPL(blk_fill_rwbs);
>>
>> #endif /* CONFIG_EVENT_TRACING */
>>
>
>
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 3/4] Export blk_fill_rwbs()
2013-02-01 3:57 ` Li Zefan
@ 2013-02-01 4:06 ` Steven Rostedt
0 siblings, 0 replies; 21+ messages in thread
From: Steven Rostedt @ 2013-02-01 4:06 UTC (permalink / raw)
To: Li Zefan
Cc: Kent Overstreet, linux-kernel, linux-bcache, Frederic Weisbecker,
Ingo Molnar
On Fri, 2013-02-01 at 11:57 +0800, Li Zefan wrote:
> on 2013/2/1 11:48, Steven Rostedt wrote:
> > Li,
> >
> > Can you give an Ack or Nack for this.
> >
>
> I think this patch shouldn't go into upstream without bcache code. We don't
> export symbols for out of tree code.
>
Even for GPL code? I have no problem either way, as we never guarantee a
module ABI. Hence, if it is exported, there's no guarantee that it will
exist or even act the same in later versions.
Kernel modules (internal, external, GPL or not) don't have the luxury of
a stable ABI as user space does.
But I'll take this as a Nack.
Thanks,
-- Steve
> >
> > On Tue, 2013-01-15 at 13:25 -0800, Kent Overstreet wrote:
> >> Exported so it can be used by bcache's tracepoints
> >>
> >> Signed-off-by: Kent Overstreet <koverstreet@google.com>
> >> CC: Steven Rostedt <rostedt@goodmis.org>
> >> CC: Frederic Weisbecker <fweisbec@gmail.com>
> >> CC: Ingo Molnar <mingo@redhat.com>
> >> ---
> >> kernel/trace/blktrace.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
> >> index c0bd030..dbe1667 100644
> >> --- a/kernel/trace/blktrace.c
> >> +++ b/kernel/trace/blktrace.c
> >> @@ -1806,6 +1806,7 @@ void blk_fill_rwbs(char *rwbs, u32 rw, int bytes)
> >>
> >> rwbs[i] = '\0';
> >> }
> >> +EXPORT_SYMBOL_GPL(blk_fill_rwbs);
> >>
> >> #endif /* CONFIG_EVENT_TRACING */
> >>
> >
> >
> >
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH 4/4] Export __lockdep_no_validate__
2013-01-14 22:32 Bcache v. whatever Kent Overstreet
` (4 preceding siblings ...)
2013-01-15 21:25 ` [PATCH 3/4] Export blk_fill_rwbs() Kent Overstreet
@ 2013-01-15 21:25 ` Kent Overstreet
2013-04-25 23:17 ` Bcache v. whatever Andrew Morton
6 siblings, 0 replies; 21+ messages in thread
From: Kent Overstreet @ 2013-01-15 21:25 UTC (permalink / raw)
To: linux-kernel, linux-bcache; +Cc: Kent Overstreet, Peter Zijlstra, Ingo Molnar
Hack, but bcache needs a way around lockdep for locking during garbage
collection - we need to keep multiple btree nodes locked for coalescing
and rw_lock_nested() isn't really sufficient or appropriate here.
Signed-off-by: Kent Overstreet <koverstreet@google.com>
CC: Peter Zijlstra <peterz@infradead.org>
CC: Ingo Molnar <mingo@redhat.com>
---
kernel/lockdep.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/lockdep.c b/kernel/lockdep.c
index 7981e5b..861fbeb 100644
--- a/kernel/lockdep.c
+++ b/kernel/lockdep.c
@@ -2997,6 +2997,7 @@ void lockdep_init_map(struct lockdep_map *lock, const char *name,
EXPORT_SYMBOL_GPL(lockdep_init_map);
struct lock_class_key __lockdep_no_validate__;
+EXPORT_SYMBOL_GPL(__lockdep_no_validate__);
static int
print_lock_nested_lock_not_held(struct task_struct *curr,
--
1.7.12
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Bcache v. whatever
2013-01-14 22:32 Bcache v. whatever Kent Overstreet
` (5 preceding siblings ...)
2013-01-15 21:25 ` [PATCH 4/4] Export __lockdep_no_validate__ Kent Overstreet
@ 2013-04-25 23:17 ` Andrew Morton
2013-04-26 19:46 ` Kent Overstreet
6 siblings, 1 reply; 21+ messages in thread
From: Andrew Morton @ 2013-04-25 23:17 UTC (permalink / raw)
To: Kent Overstreet
Cc: linux-kernel, linux-bcache, tj, axboe, James.Bottomley, snitzer
On Mon, 14 Jan 2013 14:32:02 -0800 Kent Overstreet <koverstreet@google.com> wrote:
> Bcache: a block layer SSD cache
sparc64 gcc-3.4.5:
drivers/md/bcache/btree.c: In function `bch_btree_read':
drivers/md/bcache/btree.c:266: error: invalid operands to binary +
drivers/md/bcache/btree.c: In function `__btree_write':
drivers/md/bcache/btree.c:379: error: invalid operands to binary +
drivers/md/bcache/btree.c: In function `btree_node_free':
drivers/md/bcache/btree.c:980: error: invalid operands to binary +
drivers/md/bcache/btree.c: In function `btree_insert_key':
drivers/md/bcache/btree.c:1857: error: invalid operands to binary +
drivers/md/bcache/btree.c:1857: error: invalid operands to binary +
drivers/md/bcache/btree.c:1859: error: invalid operands to binary +
drivers/md/bcache/btree.c:1859: error: invalid operands to binary +
drivers/md/bcache/btree.c:1864: error: invalid operands to binary +
drivers/md/bcache/btree.c:1864: error: invalid operands to binary +
drivers/md/bcache/btree.c: In function `btree_split':
drivers/md/bcache/btree.c:1934: error: invalid operands to binary +
drivers/md/bcache/btree.c: In function `bch_btree_set_root':
drivers/md/bcache/btree.c:2159: error: invalid operands to binary +
drivers/md/bcache/btree.c: In function `bch_btree_search_recurse':
drivers/md/bcache/btree.c:2262: error: invalid operands to binary +
drivers/md/bcache/btree.c: In function `bch_btree_refill_keybuf':
drivers/md/bcache/btree.c:2330: error: invalid operands to binary +
due to
#define pbtree(b) (&bch_pbtree(b).s[0])
I don't know why this is happening (presumably a gcc glitch), but
returning an 80-byte struct by value from bch_pkey() and bch_pbtree()
is just gruesome. The compiler has to allocate the space on the caller
stack, pass a hidden pointer into the callee and the callee copies its
return value into that caller stack slot. It's slow and consumes stack.
Something different, please.
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Bcache v. whatever
2013-04-25 23:17 ` Bcache v. whatever Andrew Morton
@ 2013-04-26 19:46 ` Kent Overstreet
2013-04-26 20:24 ` Andrew Morton
0 siblings, 1 reply; 21+ messages in thread
From: Kent Overstreet @ 2013-04-26 19:46 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, linux-bcache, tj, axboe, James.Bottomley, snitzer
On Thu, Apr 25, 2013 at 04:17:04PM -0700, Andrew Morton wrote:
> On Mon, 14 Jan 2013 14:32:02 -0800 Kent Overstreet <koverstreet@google.com> wrote:
>
> > Bcache: a block layer SSD cache
>
> sparc64 gcc-3.4.5:
>
> drivers/md/bcache/btree.c: In function `bch_btree_read':
> drivers/md/bcache/btree.c:266: error: invalid operands to binary +
> drivers/md/bcache/btree.c: In function `__btree_write':
> drivers/md/bcache/btree.c:379: error: invalid operands to binary +
> drivers/md/bcache/btree.c: In function `btree_node_free':
> drivers/md/bcache/btree.c:980: error: invalid operands to binary +
> drivers/md/bcache/btree.c: In function `btree_insert_key':
> drivers/md/bcache/btree.c:1857: error: invalid operands to binary +
> drivers/md/bcache/btree.c:1857: error: invalid operands to binary +
> drivers/md/bcache/btree.c:1859: error: invalid operands to binary +
> drivers/md/bcache/btree.c:1859: error: invalid operands to binary +
> drivers/md/bcache/btree.c:1864: error: invalid operands to binary +
> drivers/md/bcache/btree.c:1864: error: invalid operands to binary +
> drivers/md/bcache/btree.c: In function `btree_split':
> drivers/md/bcache/btree.c:1934: error: invalid operands to binary +
> drivers/md/bcache/btree.c: In function `bch_btree_set_root':
> drivers/md/bcache/btree.c:2159: error: invalid operands to binary +
> drivers/md/bcache/btree.c: In function `bch_btree_search_recurse':
> drivers/md/bcache/btree.c:2262: error: invalid operands to binary +
> drivers/md/bcache/btree.c: In function `bch_btree_refill_keybuf':
> drivers/md/bcache/btree.c:2330: error: invalid operands to binary +
>
> due to
>
> #define pbtree(b) (&bch_pbtree(b).s[0])
>
> I don't know why this is happening (presumably a gcc glitch), but
> returning an 80-byte struct by value from bch_pkey() and bch_pbtree()
> is just gruesome. The compiler has to allocate the space on the caller
> stack, pass a hidden pointer into the callee and the callee copies its
> return value into that caller stack slot. It's slow and consumes stack.
>
> Something different, please.
Well, it is kind of... perverse but really the compiler's doing exactly
what I would've had to do otherwise - stick a char buf[80] on the
caller's stack and pass it to bch_pbtree(). With the caveat that I
haven't looked at the generated code.
As far as I can tell the only real improvement would be to add a %p
format string to vsnprintf, but adding a global extension would obviously be
inappropriate for this. It'd be really nice to have a mechanism for
adding file/module private format strings to vsnprintf, but I haven't
cared enough yet to implement it myself.
Of course if you know a better solution I'm all ears.
Uhm, as for the actual bug - that is a fairly ancient gcc, I wasn't
aware we were supporting compilers that old but I'm sure you wouldn't be
bugging me about it if we weren't...
If you _really_ want me to rip out the macro/struct return hack I
will... but this is just debug code and I hate making it more verbose if
I don't have to.
Otherwise, I'll set up gcc-3.4.5 (hopefully it doesn't have to be a
sparc compiler :P) and see if I can get gcc to stop complaining.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bcache v. whatever
2013-04-26 19:46 ` Kent Overstreet
@ 2013-04-26 20:24 ` Andrew Morton
2013-04-26 20:54 ` Kent Overstreet
0 siblings, 1 reply; 21+ messages in thread
From: Andrew Morton @ 2013-04-26 20:24 UTC (permalink / raw)
To: Kent Overstreet
Cc: linux-kernel, linux-bcache, tj, axboe, James.Bottomley, snitzer
On Fri, 26 Apr 2013 12:46:42 -0700 Kent Overstreet <koverstreet@google.com> wrote:
> On Thu, Apr 25, 2013 at 04:17:04PM -0700, Andrew Morton wrote:
> > On Mon, 14 Jan 2013 14:32:02 -0800 Kent Overstreet <koverstreet@google.com> wrote:
> >
> ...
> > drivers/md/bcache/btree.c: In function `bch_btree_refill_keybuf':
> > drivers/md/bcache/btree.c:2330: error: invalid operands to binary +
> >
> > due to
> >
> > #define pbtree(b) (&bch_pbtree(b).s[0])
> >
> > I don't know why this is happening (presumably a gcc glitch), but
> > returning an 80-byte struct by value from bch_pkey() and bch_pbtree()
> > is just gruesome. The compiler has to allocate the space on the caller
> > stack, pass a hidden pointer into the callee and the callee copies its
> > return value into that caller stack slot. It's slow and consumes stack.
> >
> > Something different, please.
>
> Well, it is kind of... perverse but really the compiler's doing exactly
> what I would've had to do otherwise - stick a char buf[80] on the
> caller's stack and pass it to bch_pbtree(). With the caveat that I
> haven't looked at the generated code.
That's the more idiomatic way of doing things and yes, the code
generation will be similarly awful.
> As far as I can tell the only real improvement would be to add a %p
> format string to vsnprintf, but adding a global extension would obviously be
> inappropriate for this. It'd be really nice to have a mechanism for
> adding file/module private format strings to vsnprintf, but I haven't
> cared enough yet to implement it myself.
>
> Of course if you know a better solution I'm all ears.
>
> Uhm, as for the actual bug - that is a fairly ancient gcc, I wasn't
> aware we were supporting compilers that old but I'm sure you wouldn't be
> bugging me about it if we weren't...
Documentation/Changes is the official status. It says gcc-3.2+. We're
very slow in updating those version numbers because it's hard.
gcc-3.4.5 for mips fails in the same way.
Why are those things macros anyway? urgh, it's because we want to jam
a string into the caller's stack frame without declaring any of it.
Really I do think it would be better to do away with the C party tricks
and have callers do
char btree_buf[BTREE_BUF_SIZE];
btree_to_text(btree_buf, b);
pr_debug("%s\n", btree_buf);
Nice, simple, explicit, direct and stupid. It might generate
unused-var warnings if DEBUG is undefined but from my reading of
pr_debug() things will be OK.
Then we can poke around at btree_to_text() until gcc-3.4.5 is happy
with it.
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Bcache v. whatever
2013-04-26 20:24 ` Andrew Morton
@ 2013-04-26 20:54 ` Kent Overstreet
0 siblings, 0 replies; 21+ messages in thread
From: Kent Overstreet @ 2013-04-26 20:54 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, linux-bcache, tj, axboe, James.Bottomley, snitzer
On Fri, Apr 26, 2013 at 01:24:38PM -0700, Andrew Morton wrote:
> > As far as I can tell the only real improvement would be to add a %p
> > format string to vsnprintf, but adding a global extension would obviously be
> > inappropriate for this. It'd be really nice to have a mechanism for
> > adding file/module private format strings to vsnprintf, but I haven't
> > cared enough yet to implement it myself.
> >
> > Of course if you know a better solution I'm all ears.
> >
> > Uhm, as for the actual bug - that is a fairly ancient gcc, I wasn't
> > aware we were supporting compilers that old but I'm sure you wouldn't be
> > bugging me about it if we weren't...
>
> Why are those things macros anyway? urgh, it's because we want to jam
> a string into the caller's stack frame without declaring any of it.
Well, it also _used_ to be the case that if DEBUG and
CONFIG_DYNAMIC_DEBUG weren't defined then pr_debug() was defined as an
empty macro, so btree_to_text() wouldn't be called.
But, I just checked and it's been converted to an empty inline
function, and some of this debug code is called from fast paths where
the overhead really does matter :/ argh
> Really I do think it would be better to do away with the C party tricks
> and have callers do
>
> char btree_buf[BTREE_BUF_SIZE];
>
> btree_to_text(btree_buf, b);
> pr_debug("%s\n", btree_buf);
>
> Nice, simple, explicit, direct and stupid. It might generate
> unused-var warnings if DEBUG is undefined but from my reading of
> pr_debug() things will be OK.
>
> Then we can poke around at btree_to_text() until gcc-3.4.5 is happy
> with it.
Well, since pr_debug() isn't an empty macro anymore there goes my main
reason for keeping these macros around.
seems like pr_debug() could still have the no_printk() call inside an
if (0) though...
argh. If there was some way to tell gcc "this function only modifies
this argument so you don't have to call it if the output is never used"
then I'd just convert it to the explicit bufs now. But I really can't
have btree_to_text()/bkey_to_text() getting called in non debug
kernels...
I'm going to mull it over a bit for now, and try and decide what's least
ugly.
^ permalink raw reply [flat|nested] 21+ messages in thread