Patchwork [RESEND,for,1.4-stable] net: reduce memory allocation when multiqueue is not used

login
register
mail settings
Submitter Jason Wang
Date Feb. 20, 2013, 10:11 a.m.
Message ID <1361355093-52239-1-git-send-email-jasowang@redhat.com>
Download mbox | patch
Permalink /patch/222036/
State New
Headers show

Comments

Jason Wang - Feb. 20, 2013, 10:11 a.m.
Edivaldo reports a problem that the array of NetClientState in NICState is too
large - MAX_QUEUE_NUM(1024) which will waste memory even if multiqueue is not
used.

For 1.4 we can just solve this by reduce the MAX_QUEUE_NUM to 8 which is the
same as the current kernel (3.8+) tap queue limit. For 1.5, we will use dynamic
allocation instead.

Cc: Edivaldo de Araujo Pereira <edivaldoapereira@yahoo.com.br>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
RESEND since the previous mail misses the list.
---
 include/net/net.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
Stefan Hajnoczi - Feb. 20, 2013, 1:01 p.m.
On Wed, Feb 20, 2013 at 06:11:33PM +0800, Jason Wang wrote:
> Edivaldo reports a problem that the array of NetClientState in NICState is too
> large - MAX_QUEUE_NUM(1024) which will waste memory even if multiqueue is not
> used.
> 
> For 1.4 we can just solve this by reduce the MAX_QUEUE_NUM to 8 which is the
> same as the current kernel (3.8+) tap queue limit. For 1.5, we will use dynamic
> allocation instead.
> 
> Cc: Edivaldo de Araujo Pereira <edivaldoapereira@yahoo.com.br>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> RESEND since the previous mail misses the list.
> ---
>  include/net/net.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Is dynamic allocation much more complex?  If it takes another 2 or 3
days to come up with a patch, then that would be preferrable to a static
8 queue limit.

Stefan
Jason Wang - Feb. 21, 2013, 5:23 a.m.
On 02/20/2013 09:01 PM, Stefan Hajnoczi wrote:
> On Wed, Feb 20, 2013 at 06:11:33PM +0800, Jason Wang wrote:
>> Edivaldo reports a problem that the array of NetClientState in NICState is too
>> large - MAX_QUEUE_NUM(1024) which will waste memory even if multiqueue is not
>> used.
>>
>> For 1.4 we can just solve this by reduce the MAX_QUEUE_NUM to 8 which is the
>> same as the current kernel (3.8+) tap queue limit. For 1.5, we will use dynamic
>> allocation instead.
>>
>> Cc: Edivaldo de Araujo Pereira <edivaldoapereira@yahoo.com.br>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
>> RESEND since the previous mail misses the list.
>> ---
>>  include/net/net.h |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
> Is dynamic allocation much more complex?  If it takes another 2 or 3
> days to come up with a patch, then that would be preferrable to a static
> 8 queue limit.
>
> Stefan
>

Should be not complex, will do it.

Thanks

Patch

diff --git a/include/net/net.h b/include/net/net.h
index 43a045e..cdffc34 100644
--- a/include/net/net.h
+++ b/include/net/net.h
@@ -9,7 +9,7 @@ 
 #include "migration/vmstate.h"
 #include "qapi-types.h"
 
-#define MAX_QUEUE_NUM 1024
+#define MAX_QUEUE_NUM 8
 
 struct MACAddr {
     uint8_t a[6];