Hi,
On Tue, Jun 09, 2015 at 11:42:29AM -0600, Jens Axboe wrote:
> There are a few options to handle this. The attached might work, not
> tested at all. Basically it adds an io sched registration hook, that is
> called when we are adding the disk on the queue. Non-rotational
> detection should be
Hi,
On Tue, Jun 09, 2015 at 11:42:29AM -0600, Jens Axboe wrote:
There are a few options to handle this. The attached might work, not
tested at all. Basically it adds an io sched registration hook, that is
called when we are adding the disk on the queue. Non-rotational
detection should be done
Hi,
On Tue, May 19, 2015 at 01:55:21PM -0700, Tahsin Erdogan wrote:
> --- a/block/cfq-iosched.c
> +++ b/block/cfq-iosched.c
> @@ -4460,7 +4460,7 @@ static int cfq_init_queue(struct request_queue *q,
> struct elevator_type *e)
> cfqd->cfq_slice[1] = cfq_slice_sync;
>
Hi,
On Tue, May 19, 2015 at 01:55:21PM -0700, Tahsin Erdogan wrote:
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -4460,7 +4460,7 @@ static int cfq_init_queue(struct request_queue *q,
struct elevator_type *e)
cfqd-cfq_slice[1] = cfq_slice_sync;
cfqd-cfq_target_latency
On Mon, Oct 13, 2014 at 04:24:53AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.17.1 release.
> There are 25 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Mon, Oct 13, 2014 at 04:24:53AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.17.1 release.
There are 25 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
chael, I'm glad to see that this change made its way into
mainline after all! Would you be willing to take the following on top?
From: Romain Francoise
Date: Thu, 12 Jun 2014 10:26:40 +0200
Subject: [PATCH] vhost-net: don't open-code kvfree
Commit 23cc5a991c ("vhost-net: extend device allocation to vmalloc
that this change made its way into
mainline after all! Would you be willing to take the following on top?
From: Romain Francoise rom...@orebokech.com
Date: Thu, 12 Jun 2014 10:26:40 +0200
Subject: [PATCH] vhost-net: don't open-code kvfree
Commit 23cc5a991c (vhost-net: extend device allocation
"Michael S. Tsirkin" writes:
> Please dont' do this, extra indirection hurts performance.
> Instead, please change vhost_net_open and scsi to allocate the whole
> structure with vmalloc if kmalloc fails, along the lines of
> 74d332c13b2148ae934ea94dac1745ae92efe8e5
Back in January 2013, you
Michael S. Tsirkin m...@redhat.com writes:
Please dont' do this, extra indirection hurts performance.
Instead, please change vhost_net_open and scsi to allocate the whole
structure with vmalloc if kmalloc fails, along the lines of
74d332c13b2148ae934ea94dac1745ae92efe8e5
Back in January
Johan Hovold writes:
> So I guess that idle-active difference is normal for acpi-cpufreq and
> that the problem only arises in or with the intel_pstate driver.
I've also noticed some performance issues with intel_pstate in powersave
mode, in my case playing fullscreen video was very choppy.
Johan Hovold jhov...@gmail.com writes:
So I guess that idle-active difference is normal for acpi-cpufreq and
that the problem only arises in or with the intel_pstate driver.
I've also noticed some performance issues with intel_pstate in powersave
mode, in my case playing fullscreen video was
"Michael S. Tsirkin" writes:
> On Wed, Jan 23, 2013 at 09:46:47PM +0100, Romain Francoise wrote:
>> Creating a vhost-net device allocates an object large enough (34320 bytes
>> on x86-64) to trigger an order-4 allocation, which may fail if memory if
>> fra
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Jan 23, 2013 at 09:46:47PM +0100, Romain Francoise wrote:
Creating a vhost-net device allocates an object large enough (34320 bytes
on x86-64) to trigger an order-4 allocation, which may fail if memory if
fragmented:
libvirtd: page
David Miller writes:
> I'm not going to apply this vmalloc patch, because if I apply it the
> fundamental problem here just gets swept under the carpet even longer.
No problem, I'll keep this as a local change until vhost-net's allocation
strategy gains some sanity.
Thanks.
--
To unsubscribe
David Miller da...@davemloft.net writes:
I'm not going to apply this vmalloc patch, because if I apply it the
fundamental problem here just gets swept under the carpet even longer.
No problem, I'll keep this as a local change until vhost-net's allocation
strategy gains some sanity.
Thanks.
--
, object size: 65536, order: 4
node 0: slabs: 8/8, objs: 8/8, free: 0
In that situation, rather than forcing the caller to use regular
virtio-net, try to allocate the descriptor with vmalloc().
Signed-off-by: Romain Francoise
---
drivers/vhost/net.c | 18 +++---
1 file changed, 15
, object size: 65536, order: 4
node 0: slabs: 8/8, objs: 8/8, free: 0
In that situation, rather than forcing the caller to use regular
virtio-net, try to allocate the descriptor with vmalloc().
Signed-off-by: Romain Francoise rom...@orebokech.com
---
drivers/vhost/net.c | 18
Willy Tarreau writes:
> That makes me think that I should try 3.8-rc2 since LRO was removed
> there :-/
Better yet, find a way to automate these tests so they can run continually
against net-next and find problems early...
--
To unsubscribe from this list: send the line "unsubscribe
Willy Tarreau w...@1wt.eu writes:
That makes me think that I should try 3.8-rc2 since LRO was removed
there :-/
Better yet, find a way to automate these tests so they can run continually
against net-next and find problems early...
--
To unsubscribe from this list: send the line unsubscribe
Marc MERLIN writes:
> I had pretty repeated crashes when plugging power back into my running
> laptop, but the display just freezes and I can't get a dump.
> For the crash here, I did: suspend to RAM, plug power back in, wake up.
> Laptop crashed about 3 seconds after wakeup.
Sounds like
Marc MERLIN m...@merlins.org writes:
I had pretty repeated crashes when plugging power back into my running
laptop, but the display just freezes and I can't get a dump.
For the crash here, I did: suspend to RAM, plug power back in, wake up.
Laptop crashed about 3 seconds after wakeup.
Hi,
Linus Torvalds writes:
> Does that fix the printk's for you too?
Yep, works for me, thanks!
Tested-by: Romain Francoise
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
Hi Linus,
Linus Torvalds writes:
> Linus Torvalds (5):
> fs/buffer.c: make block-size be per-page and protected by the page lock
> blockdev: remove bd_block_size_semaphore again
> direct-io: don't read inode->i_blkbits multiple times
> blkdev_max_block: make private to
Hi Linus,
Linus Torvalds torva...@linux-foundation.org writes:
Linus Torvalds (5):
fs/buffer.c: make block-size be per-page and protected by the page lock
blockdev: remove bd_block_size_semaphore again
direct-io: don't read inode-i_blkbits multiple times
Hi,
Linus Torvalds torva...@linux-foundation.org writes:
Does that fix the printk's for you too?
Yep, works for me, thanks!
Tested-by: Romain Francoise rom...@orebokech.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
Pawel Moll writes:
> Since commit 1f2bfbd00e466ff3489b2ca5cc75b1cccd14c123 "kbuild:
> link of vmlinux moved to a script" make clean with M=
> argument (so cleaning external module) removes vmlinux,
> System.map and couple of other files from the *main* kernel
> build directory! This not what was
Pawel Moll pawel.m...@arm.com writes:
Since commit 1f2bfbd00e466ff3489b2ca5cc75b1cccd14c123 kbuild:
link of vmlinux moved to a script make clean with M=dir
argument (so cleaning external module) removes vmlinux,
System.map and couple of other files from the *main* kernel
build directory!
Linus Torvalds writes:
> I like how the default makefiles do that "create and use random key"
> thing by default. THAT is what I want to see.
Yes, however the key generation itself is horribly verbose and doesn't mix
very well with the output of a parallel build. Now that the modules are
signed
Linus Torvalds torva...@linux-foundation.org writes:
I like how the default makefiles do that create and use random key
thing by default. THAT is what I want to see.
Yes, however the key generation itself is horribly verbose and doesn't mix
very well with the output of a parallel build. Now
Hi Willy,
Willy Tarreau writes:
> RDRAND certainly qualifies as a source of entropy and I judged it was
> appropriate for a backport for this reason. Nobody has objected about
> this during the review, but maybe you have a different opinion and valid
> reasons for these patches to be reverted ?
Hi Willy,
Willy Tarreau w...@1wt.eu writes:
RDRAND certainly qualifies as a source of entropy and I judged it was
appropriate for a backport for this reason. Nobody has objected about
this during the review, but maybe you have a different opinion and valid
reasons for these patches to be
Hi Willy,
Willy Tarreau writes:
> I've just released Linux 2.6.32.60.
> This release contains, among others, a number of fixes for random and NTP,
> including for the NTP leap second bug. Users should upgrade.
I'm somewhat surprised to see that it also includes a new feature, namely
support
Hi Willy,
Willy Tarreau w...@1wt.eu writes:
I've just released Linux 2.6.32.60.
This release contains, among others, a number of fixes for random and NTP,
including for the NTP leap second bug. Users should upgrade.
I'm somewhat surprised to see that it also includes a new feature, namely
'll end up
> using the fallback code-path even when we could still execute
> the digest function. However, this isn't a big deal as nobody
> but the test path would supply zero-length associated data.
>
> Reported-by: Romain Francoise
> Signed-off-by: Herbert Xu
Feel f
the fallback code-path even when we could still execute
the digest function. However, this isn't a big deal as nobody
but the test path would supply zero-length associated data.
Reported-by: Romain Francoise rom...@orebokech.com
Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
Feel free
Jussi Kivilinna writes:
> Does reverting e46e9a46386bca8e80a6467b5c643dc494861896 help?
It does, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Still seeing this BUG with -rc5, that I originally reported here:
http://marc.info/?l=linux-crypto-vger=134653220530264=2
[ 26.362567] [ cut here ]
[ 26.362583] kernel BUG at crypto/scatterwalk.c:37!
[ 26.362606] invalid opcode: [#1] SMP
[ 26.362622] Modules
Still seeing this BUG with -rc5, that I originally reported here:
http://marc.info/?l=linux-crypto-vgerm=134653220530264w=2
[ 26.362567] [ cut here ]
[ 26.362583] kernel BUG at crypto/scatterwalk.c:37!
[ 26.362606] invalid opcode: [#1] SMP
[ 26.362622]
Jussi Kivilinna jussi.kivili...@mbnet.fi writes:
Does reverting e46e9a46386bca8e80a6467b5c643dc494861896 help?
It does, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Pete Clements writes:
> Fyi:
> Get below panic with 3.6-rc2 soon after boot (hand copy of screen).
> [] ? tcp_v4_rcv+0x626/0x740
> [] ? ip_local_deliver_finish+0x6f/0x120
> [] ? ip_rcv+0x2b0/0x2b0
> [] ? ip_rcv_finish+0xe3/0x2d0
> [] ? __netif_receive_skb+03a8/0x4a0
> [] ?
Pete Clements c...@clem.clem-digital.net writes:
Fyi:
Get below panic with 3.6-rc2 soon after boot (hand copy of screen).
[c11ec9b6] ? tcp_v4_rcv+0x626/0x740
[C11ccecf] ? ip_local_deliver_finish+0x6f/0x120
[c11cce60] ? ip_rcv+0x2b0/0x2b0
[c11cc9c3] ? ip_rcv_finish+0xe3/0x2d0
[c11ae0a8]
42 matches
Mail list logo
