mm, tree wide: replace __GFP_REPEAT by
__GFP_RETRY_MAYFAIL with more useful semantic")
Signed-off-by: David Rientjes
---
net/core/skbuff.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
--- a/net/core/skbuff.c
+++ b/net/core/sk
On Wed, 25 Apr 2018, Mikulas Patocka wrote:
> You need to enable it on boot. Enabling it when the kernel starts to
> execute userspace code is already too late (because you would miss
> kvmalloc calls in the kernel boot path).
>
Is your motivation that since kvmalloc() never falls back to vmal
On Wed, 25 Apr 2018, Mikulas Patocka wrote:
> From: Mikulas Patocka
> Subject: [PATCH] fault-injection: introduce kvmalloc fallback options
>
> This patch introduces a fault-injection option "kvmalloc_fallback". This
> option makes kvmalloc randomly fall back to vmalloc.
>
> Unfortunately, some
On Mon, 23 Apr 2018, Mikulas Patocka wrote:
> The kvmalloc function tries to use kmalloc and falls back to vmalloc if
> kmalloc fails.
>
> Unfortunatelly, some kernel code has bugs - it uses kvmalloc and then
> uses DMA-API on the returned memory or frees it with kfree. Such bugs were
> found in
gt; Cc: Oleg Drokin # lustre
> Cc: Andreas Dilger # lustre
> Cc: # coda
> Cc: # jffs2
> Cc: Jan Kara # udf
> Cc: # xattr
> Cc: # ipc + mm
> Cc: # ipv4
Acked-by: David Rientjes
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the bo
On Wed, 19 Aug 2015, Patil, Kiran wrote:
> Acked-by: Kiran Patil
Where's the call to preempt_disable() to prevent kernels with preemption
from making numa_node_id() invalid during this iteration?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ma
On Mon, 17 Aug 2015, Jiang Liu wrote:
> Function i40e_clean_rx_irq() tries to reuse memory pages allocated
s/i40e_clean_rx_irq/i40e_clean_rx_irq_ps/
> from the nearest node. To better support memoryless node, use
> numa_mem_id() instead of numa_node_id() to get the nearest node with
> memory.
>
On Thu, 18 Jun 2015, Michal Hocko wrote:
> That is to be discussed. Most allocations already express their interest
> in memory reserves by __GFP_HIGH directly or by GFP_ATOMIC indirectly.
> So maybe we do not need any additional flag here. There are not that
> many ~__GFP_WAIT and most of them se
On Fri, 12 Jun 2015, Vlastimil Babka wrote:
> > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > index 3cfff2a..41ec022 100644
> > --- a/net/core/skbuff.c
> > +++ b/net/core/skbuff.c
> > @@ -4398,7 +4398,7 @@ struct sk_buff *alloc_skb_with_frags(unsigned long
> > header_len,
> >
> >
On Thu, 7 Feb 2008, Sven Wegener wrote:
> Negative values will be converted to MAX_JIFFY_OFFSET by msecs_to_jiffies and
> result in a very long interval. A too long interval will be a good way to get
> your system OOM. We could use an unsigned int or even restrict the value with
> proc_dointvec_mi
On Wed, 6 Feb 2008, Sven Wegener wrote:
> diff --git a/net/ipv4/ipvs/ip_vs_sync.c b/net/ipv4/ipvs/ip_vs_sync.c
> index 948378d..9b57ad3 100644
> --- a/net/ipv4/ipvs/ip_vs_sync.c
> +++ b/net/ipv4/ipvs/ip_vs_sync.c
> @@ -143,6 +143,8 @@ char ip_vs_backup_mcast_ifn[IP_VS_IFNAME_MAXLEN];
> /* multica
11 matches
Mail list logo
