Re: [PATCH 1/2] Convert target drivers to use sbitmap

On 5/15/18 10:11 AM, Jens Axboe wrote: > On 5/15/18 10:00 AM, Matthew Wilcox wrote: >> From: Matthew Wilcox <mawil...@microsoft.com> >> >> The sbitmap and the percpu_ida perform essentially the same task, >> allocating tags for commands. Since the sbitmap is

Re: [PATCH 1/2] Convert target drivers to use sbitmap

ght make sense to just roll the whole thing into iscsi_get_tag(), that would be cleaner. sbitmap should provide a helper for that, but we can do that cleanup later. That would encapsulate things like the per-cpu caching hint too, for instance. Rest looks fine to me. -- Jens Axboe

Re: [PATCH 2/5] ide: kill ide_toggle_bounce

On 4/26/18 1:20 AM, Christoph Hellwig wrote: > On Tue, Apr 24, 2018 at 08:02:56PM -0600, Jens Axboe wrote: >> On 4/24/18 12:16 PM, Christoph Hellwig wrote: >>> ide_toggle_bounce did select various strange block bounce limits, including >>> not bouncing at all as

Re: [PATCH 2/5] ide: kill ide_toggle_bounce

of DMA, the issue was that the PIO code could not handle highmem. That's not the case anymore, so this should be fine. Reviewed-by: Jens Axboe <ax...@kernel.dk> -- Jens Axboe

Re: mlx5 broken affinity

On 11/09/2017 02:23 PM, Thomas Gleixner wrote: > On Thu, 9 Nov 2017, Jens Axboe wrote: >> On 11/09/2017 10:03 AM, Thomas Gleixner wrote: >>> On Thu, 9 Nov 2017, Jens Axboe wrote: >>>> On 11/09/2017 07:19 AM, Thomas Gleixner wrote: >>>> If that's the attit

Re: mlx5 broken affinity

On 11/09/2017 10:07 AM, Thomas Gleixner wrote: > On Thu, 9 Nov 2017, Jens Axboe wrote: > >> On 11/09/2017 09:01 AM, Sagi Grimberg wrote: >>>> Now you try to blame the people who implemented the managed affinity stuff >>>> for the wreckage, which was created

Re: mlx5 broken affinity

On 11/09/2017 10:03 AM, Thomas Gleixner wrote: > On Thu, 9 Nov 2017, Jens Axboe wrote: >> On 11/09/2017 07:19 AM, Thomas Gleixner wrote: >> If that's the attitude at your end, then I do suggest we just revert the >> driver changes. Clearly this isn't going to be pro

Re: mlx5 broken affinity

ying to understand > how to move forward with making users happy and still enjoy subsystem > services instead of doing lots of similar things inside mlx5 driver. Exactly. The key here is how we make it work for both cases. But there has to be a willingness to make the infrastructure work for that. -- Jens Axboe

Re: mlx5 broken affinity

a single patch was posted. > > Now you try to blame the people who implemented the managed affinity stuff > for the wreckage, which was created by people who changed drivers to use > it. Nice try. If that's the attitude at your end, then I do suggest we just revert the driver changes. Clearly this isn't going to be productive going forward. The better solution was to make the managed setup more flexible, but it doesn't sound like that is going to be viable at all. -- Jens Axboe

Re: mlx5 broken affinity

handle all the stuff the kernel can" > then we should document it. This is really device independent. Completely agree, and honestly I'm pretty baffled we're even having to argue this point. -- Jens Axboe

Re: mlx5 broken affinity

On 11/09/2017 03:09 AM, Christoph Hellwig wrote: > On Wed, Nov 08, 2017 at 09:13:59AM -0700, Jens Axboe wrote: >> There are numerous valid reasons to be able to set the affinity, for >> both nics and block drivers. It's great that the kernel has a predefined >> layout that wor

Re: mlx5 broken affinity

nged, setting it at bootup to a known good configuration helped eliminate problems when upgrading kernels. I also remember some cases of removing CPU0 from the mask. But that particular case is completely orthogonal to whether or not we should allow the user to reconfigure. The answer to that is cle

Re: [PATCH 13/31] timer: Remove meaningless .data/.function assignments

On 08/31/2017 05:29 PM, Kees Cook wrote: > Several timer users needlessly reset their .function/.data fields during > their timer callback, but nothing else changes them. Some users do not > use their .data field at all. Each instance is removed here. For amiflop: Acked-by: Jens

Re: [PATCH 2/6] nbd: make device_attribute const

On 08/21/2017 05:43 AM, Bhumika Goyal wrote: > Make this const as is is only passed as an argument to the > function device_create_file and device_remove_file and the corresponding > arguments are of type const. > Done using Coccinelle Added for 4.14, thanks. -- Jens Axboe

Re: [PATCH 19/22] block: DAC960: shut up format-overflow warning

and using snprintf() > instead of sprintf() improves this by ensuring that even > incorrect data won't cause undefined behavior here. Thanks Arnd, added for 4.14. -- Jens Axboe

Re: WARNING: CPU: 2 PID: 682 at net/wireless/util.c:1236

On 05/04/2017 09:27 AM, Jens Axboe wrote: > On 05/04/2017 09:25 AM, David Miller wrote: >> From: Jens Axboe <ax...@kernel.dk> >> Date: Thu, 4 May 2017 09:23:36 -0600 >> >>> Running current -git on my laptop, and I see this spew every once >>> in

Re: WARNING: CPU: 2 PID: 682 at net/wireless/util.c:1236

On 05/04/2017 09:25 AM, David Miller wrote: > From: Jens Axboe <ax...@kernel.dk> > Date: Thu, 4 May 2017 09:23:36 -0600 > >> Running current -git on my laptop, and I see this spew every once >> in a while. This is new, haven't seen it in 4.11 or previously. Driver >

WARNING: CPU: 2 PID: 682 at net/wireless/util.c:1236

: 01ffc570 [ 3285.978664] Code: d0 f7 e1 d1 ea 8d 14 92 01 d2 81 c2 50 c3 00 00 b9 c5 5a 7c 0a 5d c1 ea 05 89 d0 f7 e1 89 d0 c1 e8 07 c3 31 c0 40 80 fe 02 74 b6 <0f> ff 31 c0 eb b0 8d 14 52 01 d2 e9 41 ff ff ff 0f ff 31 c0 5d [ 3285.978693] ---[ end trace ae08dfa326cc120a ]--- -- Jens Axboe

Re: linux-next: build failure after merge of the block tree

On May 1, 2017, at 7:37 PM, Stephen Rothwell <s...@canb.auug.org.au> wrote: > > Hi Jens, > >> On Mon, 1 May 2017 19:09:34 -0600 Jens Axboe <ax...@kernel.dk> wrote: >> >> Indeed, I have warned Linus about it. Thanks Stephen. > > Thanks. > >

Re: linux-next: build failure after merge of the block tree

> On May 1, 2017, at 7:07 PM, Stephen Rothwell wrote: > > Hi all, > >> On Tue, 18 Apr 2017 13:02:29 +1000 Stephen Rothwell >> wrote: >> >> After merging the block tree, today's linux-next build (powerpc >> ppc64_defconfig) failed like this: >>

Re: [PATCH block-tree] net: off by one in inet6_pton()

On 04/13/2017 01:42 PM, Dan Carpenter wrote: > If "scope_len" is sizeof(scope_id) then we would put the NUL terminator > one space beyond the end of the buffer. Added, thanks Dan. -- Jens Axboe

Re: [PATCH rfc 5/6] block: Add rdma affinity based queue mapping helper

On 04/02/2017 07:41 AM, Sagi Grimberg wrote: > Like pci and virtio, we add a rdma helper for affinity > spreading. This achieves optimal mq affinity assignments > according to the underlying rdma device affinity maps. Reviewed-by: Jens Axboe <ax...@fb.com> -- Jens Axboe

Re: codel: split into multiple files

on, I guess you can say it pays homage to CoDel. But there are a sufficient amount of differences between networking and storage that I don't think a fully generic version is really feasible. My favorite thing to bring up is the fact that we don't have the luxury of dropping packets on the storage side... -- Jens Axboe

Re: [PATCH 1/4] list: introduce list_is_first()

really help, they hurt readability. You should know how the list works anyway, and if you do, then it's a no-brainer what's first and last. If you don't, then you are bound to screw up in other ways. Just my 2 cents. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubs

Re: [PATCH 1/4] list: introduce list_is_first()

On 12/10/2015 08:23 AM, Josh Poimboeuf wrote: On Thu, Dec 10, 2015 at 08:10:34AM -0700, Jens Axboe wrote: On 12/10/2015 07:17 AM, Geliang Tang wrote: We already have list_is_last(), it makes sense to also add list_is_first() for consistency. This list utility function to check for first

Re: 4.4-rc3, KVM, br0 and instant hang

he following crash dump (partial) on my netconsole box. [ 1434.266524] [ cut here ] [ 1434.266643] WARNING: CPU: 2 PID: 179 at block/blk-merge.c:435 blk_rq_map_sg+0x2d9/0x2eb() This is fixed in current -git, as of a few days ago. -- Jens Axboe -- To unsubscribe from this

4.3.0+ breaks software VPN

. How do we get this fixed so that 4.4-rc1 doesn't break basic VPN support? -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: 4.3.0+ breaks software VPN

On 11/13/2015 02:44 PM, Nikolay Aleksandrov wrote: On 11/13/2015 10:37 PM, Jens Axboe wrote: Hi, Tried to connect to sw vpn today, and it isn't working. Running git as-of yesterday. In dmesg: [23703.921542] vpn0: set_features() failed (-1); wanted 0x008048c1, left 0x0080001b48c9

Re: [PATCH retry] bluetooth : add conn add/del workqueues to avoid connection fail

(struct hci_conn INIT_WORK(conn-work, add_conn); + queue_work(btaddconn, conn-work); schedule_work(conn-work); } So you queue conn-work on both btaddconn and keventd_wq? -- Jens Axboe -- To unsubscribe from this list: send the line unsubscribe netdev in the body

Re: [BUG] New Kernel Bugs

the bugzilla. Did so now. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH]: Fix networking scatterlist regressions.

5a0347663f51850eb52b89c4dcf6a714ea8d3965 Mon Sep 17 00:00:00 2001 From: Jens Axboe [EMAIL PROTECTED] Date: Wed, 31 Oct 2007 08:31:23 +0100 Subject: [PATCH] [SG] Remove __sg_mark_end() Make sg_mark_end() NOT overwrite the page link. Then it can be used after filling the sg table, which is what users

Re: [PATCH]: Fix networking scatterlist regressions.

On Wed, Oct 31 2007, David Miller wrote: From: Jens Axboe [EMAIL PROTECTED] Date: Wed, 31 Oct 2007 08:32:07 +0100 [SG] Remove __sg_mark_end() Make sg_mark_end() NOT overwrite the page link. Then it can be used after filling the sg table, which is what users want. That means

Re: [PATCH]: Fix networking scatterlist regressions.

something go wrong there? -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH]: Fix networking scatterlist regressions.

On Wed, Oct 31 2007, David Miller wrote: From: Jens Axboe [EMAIL PROTECTED] Date: Wed, 31 Oct 2007 09:01:43 +0100 On Wed, Oct 31 2007, David Miller wrote: From: Jens Axboe [EMAIL PROTECTED] Date: Wed, 31 Oct 2007 08:46:21 +0100 On Tue, Oct 30 2007, David Miller wrote

Re: [PATCH]: Fix networking scatterlist regressions.

On Wed, Oct 31 2007, David Miller wrote: From: Jens Axboe [EMAIL PROTECTED] Date: Wed, 31 Oct 2007 08:46:21 +0100 On Tue, Oct 30 2007, David Miller wrote: @@ -293,7 +293,7 @@ decryptor(struct scatterlist *sg, void *data) if (thislen == 0) return 0; - sg_mark_end

Re: [PATCH]: Fix networking scatterlist regressions.

On Wed, Oct 31 2007, David Miller wrote: From: Jens Axboe [EMAIL PROTECTED] Date: Wed, 31 Oct 2007 08:46:21 +0100 On Tue, Oct 30 2007, David Miller wrote: @@ -293,7 +293,7 @@ decryptor(struct scatterlist *sg, void *data) if (thislen == 0) return 0; - sg_mark_end

Re: [PATCH]: Fix networking scatterlist regressions.

On Wed, Oct 31 2007, David Miller wrote: From: Jens Axboe [EMAIL PROTECTED] Date: Wed, 31 Oct 2007 09:14:28 +0100 Subject: [PATCH] [SG] Get rid of __sg_mark_end() sg_mark_end() overwrites the page_link information, but all users want __sg_mark_end() behaviour where we just set the end

Re: [PATCH]: Fix networking scatterlist regressions.

was definitely non-intuitive! -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] [CRYPTO] tcrypt: Move sg_init_table out of timing loops

On Tue, Oct 30 2007, Boaz Harrosh wrote: On Mon, Oct 29 2007 at 22:16 +0200, Jens Axboe [EMAIL PROTECTED] wrote: On Fri, Oct 26 2007, Herbert Xu wrote: [CRYPTO] tcrypt: Move sg_init_table out of timing loops This patch moves the sg_init_table out of the timing loops for hash algorithms

Re: [PATCH 1/2] [CRYPTO] tcrypt: Move sg_init_table out of timing loops

On Tue, Oct 30 2007, Herbert Xu wrote: On Tue, Oct 30, 2007 at 06:50:58AM +0100, Jens Axboe wrote: How so? The reason you changed it to sg_init_table() + sg_set_buf() is exactly because sg_init_one() didn't properly init the entry (as they name promised). For one of the cases yes

Re: [PATCH 1/2] [CRYPTO] tcrypt: Move sg_init_table out of timing loops

buflen) +{ + sg_init_table(sg, 1); + sg_set_buf(sg, buf, buflen); +} + +/** * sg_phys - Return physical address of an sg entry * @sg: SG entry * -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED

Re: [-mm patch] make tcp_splice_data_recv() static

... tcp_splice_data_recv() can become static. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] I'll let Jens or similar pick this one up since it obviously won't apply to my tree. I'll shove it in my #splice-net branch, where it originates from. -- Jens Axboe - To unsubscribe from this list: send the line

Re: Distributed storage.

On Sun, Aug 12 2007, Daniel Phillips wrote: On Tuesday 07 August 2007 13:55, Jens Axboe wrote: I don't like structure bloat, but I do like nice design. Overloading is a necessary evil sometimes, though. Even today, there isn't enough room to hold bi_rw and bi_flags in the same variable

Re: Distributed storage.

On Mon, Aug 13 2007, Jens Axboe wrote: You did not comment on the one about putting the bio destructor in the -endio handler, which looks dead simple. The majority of cases just use the default endio handler and the default destructor. Of the remaining cases, where a specialized

Re: Distributed storage.

On Mon, Aug 13 2007, Daniel Phillips wrote: On Monday 13 August 2007 00:28, Jens Axboe wrote: On Sun, Aug 12 2007, Daniel Phillips wrote: Right, that is done by bi_vcnt. I meant bi_max_vecs, which you can derive efficiently from BIO_POOL_IDX() provided the bio was allocated

Re: Distributed storage.

On Mon, Aug 13 2007, Daniel Phillips wrote: On Monday 13 August 2007 00:45, Jens Axboe wrote: On Mon, Aug 13 2007, Jens Axboe wrote: You did not comment on the one about putting the bio destructor in the -endio handler, which looks dead simple. The majority of cases just use

Re: Distributed storage.

On Mon, Aug 13 2007, Daniel Phillips wrote: On Monday 13 August 2007 02:13, Jens Axboe wrote: On Mon, Aug 13 2007, Daniel Phillips wrote: On Monday 13 August 2007 00:45, Jens Axboe wrote: On Mon, Aug 13 2007, Jens Axboe wrote: You did not comment on the one about putting the bio

Re: Distributed storage.

On Mon, Aug 13 2007, Daniel Phillips wrote: On Monday 13 August 2007 03:06, Jens Axboe wrote: On Mon, Aug 13 2007, Daniel Phillips wrote: Of course not. Nothing I said stops endio from being called in the usual way as well. For this to work, endio just needs to know that one call

Re: Distributed storage.

don't add temporary fields out of laziness, hoping that someone will later kill it again and rewrite it in a nicer fashion. Hint: that never happens, bloat sticks. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More

Re: Distributed storage.

On Tue, Aug 07 2007, Daniel Phillips wrote: On Tuesday 07 August 2007 05:05, Jens Axboe wrote: On Sun, Aug 05 2007, Daniel Phillips wrote: A simple way to solve the stable accounting field issue is to add a new pointer to struct bio that is owned by the top level submitter (normally

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

as argument. Signed-off-by: Jens Axboe [EMAIL PROTECTED] diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c index 5727cd1..c4034f6 100644 --- a/fs/ocfs2/file.c +++ b/fs/ocfs2/file.c @@ -2153,7 +2153,7 @@ static int ocfs2_splice_write_actor(struct pipe_inode_info *pipe, src = buf-ops-map(pipe, buf, 1

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

On Tue, Jul 24 2007, Jens Axboe wrote: On Mon, Jul 23 2007, Andrew Morton wrote: I worked out that the crash I saw was in BUG_ON(!pte_none(*(kmap_pte-idx))); in the read of kmap_pte[idx]. Which would be weird as the caller is using a literal KM_USER0. So maybe I

Re: [PATCH][RFC] network splice receive v3

On Thu, Jul 19 2007, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: Hello. In article [EMAIL PROTECTED] (at Wed, 11 Jul 2007 11:19:27 +0200), Jens Axboe [EMAIL PROTECTED] says: @@ -835,6 +835,7 @@ const struct proto_ops inet_stream_ops = { .recvmsg = sock_common_recvmsg

Re: TCP stalls in current git, possibly splice related

On Wed, Jul 18 2007, Johannes Berg wrote: On Mon, 2007-07-16 at 14:02 +0200, Jens Axboe wrote: Yep, it's a sender thing, so upgrading the receiver will not change anything. Ok, I upgraded, but that didn't help. And in fact, I don't see how it could have since synergy doesn't use splice

Re: TCP stalls in current git, possibly splice related

On Mon, Jul 16 2007, Johannes Berg wrote: On Fri, 2007-07-13 at 13:05 +0200, Jens Axboe wrote: On Fri, Jul 13 2007, Johannes Berg wrote: On Thu, 2007-07-12 at 16:12 -0400, James Morris wrote: I'm seeing TCP connection stalls with current git, and a bisect found the following

Re: [2.6 patch] more ACSI removal

On Mon, Jul 16 2007, Geert Uytterhoeven wrote: On Mon, 16 Jul 2007, Jens Axboe wrote: On Fri, Jul 13 2007, Geert Uytterhoeven wrote: On Fri, 13 Jul 2007, Adrian Bunk wrote: This patch removes some code that became dead code after the ATARI_ACSI removal. When was it removed

Re: TCP stalls in current git, possibly splice related

On Fri, Jul 13 2007, Jens Axboe wrote: On Thu, Jul 12 2007, James Morris wrote: On Thu, 12 Jul 2007, David Miller wrote: From: James Morris [EMAIL PROTECTED] Date: Thu, 12 Jul 2007 16:12:25 -0400 (EDT) I'm seeing TCP connection stalls with current git, and a bisect found

Re: [PATCH][RFC] network splice receive v3

On Thu, Jul 12 2007, Evgeniy Polyakov wrote: On Wed, Jul 11, 2007 at 11:19:27AM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote: Hi, Hi Jens. Here's an updated implementation of tcp network splice receive support. It actually works for me now, no data corruption seen

Re: TCP stalls in current git, possibly splice related

, }; - size_t ret; + long ret; ret = splice_direct_to_actor(in, sd, direct_splice_actor); - *ppos = sd.pos; + if (ret 0) + *ppos += ret; + return ret; } -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe netdev

Re: TCP stalls in current git, possibly splice related

On Fri, Jul 13 2007, Jens Axboe wrote: On Fri, Jul 13 2007, Jens Axboe wrote: On Thu, Jul 12 2007, James Morris wrote: On Thu, 12 Jul 2007, David Miller wrote: From: James Morris [EMAIL PROTECTED] Date: Thu, 12 Jul 2007 16:12:25 -0400 (EDT) I'm seeing TCP connection

Re: TCP stalls in current git, possibly splice related

to this James is seeing this with distcc I believe. Correct. I'll try and reproduce. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [2.6 patch] more ACSI removal

support - depends on ATARI ATARI_ACSI!=n + depends on ATARI Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Thanks Adrian, applied! -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info

[PATCH][RFC] network splice receive v3

in there that allows vmsplice directly to user memory, that still needs some work though. Comments, testing welcome! -- Jens Axboe From e59a68f2d7d261b301960b97659910aab8e3d776 Mon Sep 17 00:00:00 2001 From: Jens Axboe [EMAIL PROTECTED] Date: Mon, 11 Jun 2007 13:00:32 +0200 Subject: [PATCH] splice: don't

Re: [PATCH][RFC] network splice receive v3

On Wed, Jul 11 2007, Joel Becker wrote: On Wed, Jul 11, 2007 at 11:19:27AM +0200, Jens Axboe wrote: Subject: [PATCH] splice: don't assume regular pages in splice_to_pipe() Allow caller to pass in a release function, there might be other resources that need releasing as well. Needed

Re: [PATCH v2.6.22-rc5] cxgb2: handle possible NULL pointer dereferencing

this. Patch looks odd - bi is dereferenced a number of times after that loop anyway, so I don't see your patch fixing much. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org

Re: [PATCH v2.6.22-rc5] cxgb2: handle possible NULL pointer dereferencing

On Thu, Jun 21 2007, pradeep singh wrote: Hi On 6/21/07, Jens Axboe [EMAIL PROTECTED] wrote: On Thu, Jun 21 2007, pradeep singh wrote: Hi, Chelsio's in kernel 10G driver does not checks the return value from t1_get_board_info() in cxgb2.c. t1_get_board_info may return a NULL and we

Re: [PATCH][RFC] network splice receive v2

On Fri, Jun 15 2007, Evgeniy Polyakov wrote: On Thu, Jun 14, 2007 at 01:59:02PM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote: On Thu, Jun 14 2007, Evgeniy Polyakov wrote: On Wed, Jun 13, 2007 at 12:01:04PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: I will rebase my tree

Re: [PATCH][RFC] network splice receive v2

On Fri, Jun 15 2007, Evgeniy Polyakov wrote: On Fri, Jun 15, 2007 at 10:43:18AM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote: So, things turned down to be not in the __splice_from_pipe(), but splice_to_pipe(). Attached patch fixes a leak for me. It was tested with different data files

Re: [PATCH][RFC] network splice receive v2

into shape the last two days. Interesting that you mention the last page, I'll dig in now! Any more info on this (how did you notice the leak originates from there)? Thanks Jens, good work. Thanks, you're welcome! -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe netdev

Re: [PATCH][RFC] network splice receive v2

On Wed, Jun 13 2007, Evgeniy Polyakov wrote: On Tue, Jun 12, 2007 at 08:17:32PM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote: On Tue, Jun 12 2007, Evgeniy Polyakov wrote: On Mon, Jun 11, 2007 at 01:59:26PM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote: Patches are against the #splice

[PATCH 0/3] Splice network receive support

Hi, This series of patches applies on top of the splice series just posted. It implements basic network receive support, ie splicing from a socket to a pipe. There seems to be a skhead_buff_cache leak somewhere that I need to track down, otherwise it works fine for me. -- Jens Axboe

[PATCH 1/3] splice: don't assume regular pages in splice_to_pipe()

Allow caller to pass in a release function, there might be other resources that need releasing as well. Needed for network receive. Signed-off-by: Jens Axboe [EMAIL PROTECTED] --- fs/splice.c|9 - include/linux/splice.h |1 + 2 files changed, 9 insertions(+), 1

[PATCH 3/3] TCP splice receive support

Support for network splice receive. Signed-off-by: Jens Axboe [EMAIL PROTECTED] --- include/linux/net.h|3 + include/linux/skbuff.h |5 + include/net/tcp.h |3 + net/core/skbuff.c | 231 net/ipv4/af_inet.c |1

[PATCH 2/3] tcp_read_sock: alloc recv_actor() return return negative error value

Signed-off-by: Jens Axboe [EMAIL PROTECTED] --- net/ipv4/tcp.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index cd3c7e9..450f44b 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -1064,7 +1064,11 @@ int tcp_read_sock(struct

Re: [PATCH][RFC] network splice receive

On Tue, Jun 12 2007, Evgeniy Polyakov wrote: On Sat, Jun 09, 2007 at 08:36:09AM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote: On Fri, Jun 08 2007, Evgeniy Polyakov wrote: On Fri, Jun 08, 2007 at 06:57:25PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: I will try some things

Re: [PATCH][RFC] network splice receive

a leak there, but functionally it's ok!). -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH][RFC] network splice receive

code than the newest :-) -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH][RFC] network splice receive v2

On Tue, Jun 12 2007, Evgeniy Polyakov wrote: On Mon, Jun 11, 2007 at 01:59:26PM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote: Patches are against the #splice branch of the block repo, official url of that is: git://git.kernel.dk/data/git/linux-2.6-block.git/ and it's based on Linus

Re: [PATCH][RFC] network splice receive

at least. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH][RFC] network splice receive v2

on Linus main tree. Let me know if I should supply netdev branch patches instead, or even just provide a rolled up patch (or patch series) for anyone curious to test or play with it. -- Jens Axboe From fd79bf84fdeb15b72f256c342609257ae8a56235 Mon Sep 17 00:00:00 2001 From: Jens Axboe [EMAIL PROTECTED

Re: [PATCH][RFC] network splice receive

fast clone is unused in most cases, so there might be some gain. Attached your patch with above changes. Thanks, I'll fiddle with this on monday. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info

Re: [PATCH][RFC] network splice receive

On Thu, Jun 07 2007, Evgeniy Polyakov wrote: On Thu, Jun 07, 2007 at 12:51:59PM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote: What bout checking if page belongs to kmalloc cache (or any other cache via priviate pointers) and do not perform any kind of reference counting on them? I

Re: [PATCH][RFC] network splice receive

On Fri, Jun 08 2007, David Miller wrote: From: Jens Axboe [EMAIL PROTECTED] Date: Fri, 8 Jun 2007 09:48:24 +0200 Perhaps it's possible to solve this at a different level - can we hang on to the skb until the pipe buffer has been consumed, and prevent reuse that way? Then we don't have

Re: [PATCH][RFC] network splice receive

On Fri, Jun 08 2007, Evgeniy Polyakov wrote: On Fri, Jun 08, 2007 at 10:38:53AM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote: On Fri, Jun 08 2007, David Miller wrote: From: Jens Axboe [EMAIL PROTECTED] Date: Fri, 8 Jun 2007 09:48:24 +0200 Perhaps it's possible to solve

Re: [PATCH][RFC] network splice receive

On Fri, Jun 08 2007, Evgeniy Polyakov wrote: On Fri, Jun 08, 2007 at 11:04:40AM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote: OK, so a delayed empty of the pipe could end up causing packet drops elsewhere due to allocation exhaustion? Yes. We can grow the pipe, should we have to. So

Re: [PATCH][RFC] network splice receive

On Fri, Jun 08 2007, Evgeniy Polyakov wrote: On Fri, Jun 08, 2007 at 04:14:52PM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote: Here's a start, for the splice side at least of storing a buf-private entity with the ops. :) I tested the same implementation, but I put skb pointer into page

Re: [PATCH][RFC] network splice receive

On Thu, Jun 07 2007, Evgeniy Polyakov wrote: On Wed, Jun 06, 2007 at 09:17:25AM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote: Some pages have zero reference counter here. But it's somewhat annoying to get pages with zero reference counts there, I wonder how that happens. I guess

Re: [PATCH][RFC] network splice receive

On Tue, Jun 05 2007, jamal wrote: On Tue, 2007-05-06 at 14:20 +0200, Jens Axboe wrote: 1800 4ff3 937f e000 6381 7275 0008 Perhaps that hex pattern rings a bell with someone intimate with the networking. The remaining wrong bytes don't seem to have anything in common

Re: [PATCH][RFC] network splice receive

On Tue, Jun 05 2007, Evgeniy Polyakov wrote: On Tue, Jun 05, 2007 at 10:05:43AM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote: Here's an implementation of tcp network splice receive support. It's originally based on the patch set that Intel posted some time ago, but has been (close to) 100

[PATCH][RFC] network splice receive

supply netdev branch patches instead. -- Jens Axboe From 592c46ea813c31c0d6b28bf543ce2f5dd884a75e Mon Sep 17 00:00:00 2001 From: Jens Axboe [EMAIL PROTECTED] Date: Mon, 4 Jun 2007 15:06:43 +0200 Subject: [PATCH] [NET] tcp_read_sock: alloc recv_actor() return return negative error value Signed-off

Re: [PATCH][RFC] network splice receive

On Tue, Jun 05 2007, Jens Axboe wrote: Seems to work reasonably well for me, sometimes I do see small ranges inside the output file that are not correct, but I haven't been able to reproduce today. I think it has to do with page reuse, hence the NET_COPY_SPLICE ifdef that you can enable

Re: [PATCH][RFC] network splice receive

On Tue, Jun 05 2007, Jens Axboe wrote: On Tue, Jun 05 2007, Jens Axboe wrote: Seems to work reasonably well for me, sometimes I do see small ranges inside the output file that are not correct, but I haven't been able to reproduce today. I think it has to do with page reuse, hence

Re: default y idiocy

On Sat, May 12 2007, Simon Arlott wrote: On 12/05/07 19:23, Jens Axboe wrote: Hi, This has bothered me for a long time, and it just seems to be getting worse. Can people please STOP defaulting non-essential stuff to 'y'? Grrr. Is there a reason why various 10/100/1000Mbit network cards

Re: [PATCH] Revert [NET_SCHED]: HTB: fix incorrect use of RB_EMPTY_NODE

is empty as expected. ... - if (!RB_EMPTY_NODE(rb)) { + if (RB_EMPTY_NODE(rb)) { Maybe you have some kind of agreement with Jens Axboe but I can't understand current way of kernel cooperation: he changes some global behavior to the opposite and fixes his code in three places

Re: [PATCH] Revert [NET_SCHED]: HTB: fix incorrect use of RB_EMPTY_NODE

the node is empty as expected. ... - if (!RB_EMPTY_NODE(rb)) { + if (RB_EMPTY_NODE(rb)) { Maybe you have some kind of agreement with Jens Axboe but I can't understand current way of kernel cooperation: he changes some global behavior to the opposite and fixes his code in three

Re: [PATCH 11/20] nbd: request_fn fixup

On Tue, Sep 12 2006, Jeff Garzik wrote: Jens Axboe wrote: Generally the block device rule is that once you are invoked due to an unplug (or whatever) event, it is the responsibility of the block device to run the queue until it's done. So if you bail out of queue handling for whatever reason

Re: [PATCH 11/20] nbd: request_fn fixup

already have pending work where you can invoke queueing from again. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/21] block: elevator selection and pinning

On Thu, Sep 07 2006, Peter Zijlstra wrote: On Wed, 2006-09-06 at 15:46 +0200, Jens Axboe wrote: On Wed, Sep 06 2006, Peter Zijlstra wrote: Provide an block queue init function that allows to set an elevator. And a function to pin the current elevator. Signed-off-by: Peter

Re: [PATCH 10/21] block: elevator selection and pinning

On Wed, Sep 06 2006, Peter Zijlstra wrote: Provide an block queue init function that allows to set an elevator. And a function to pin the current elevator. Signed-off-by: Peter Zijlstra [EMAIL PROTECTED] Signed-off-by: Daniel Phillips [EMAIL PROTECTED] CC: Jens Axboe [EMAIL PROTECTED] CC

Re: [PATCH 11/21] nbd: limit blk_queue

what happens if the noop scheduler isn't compiled into the kernel? You can't de-select noop, so that cannot happen. But the point is valid for other choices of io schedulers, which is another reason why this _elv api addition is a bad idea. -- Jens Axboe - To unsubscribe from this list: send

  1   2   >