* Re: [PATCH 38 of 39] IB/ipath - More changes to support InfiniPath on PowerPC 970 systems
From: David Miller @ 2006-06-29 21:53 UTC (permalink / raw)
To: bos; +Cc: akpm, rdreier, mst, openib-general, linux-kernel, netdev
In-Reply-To: <c22b6c244d5db77f7b1d.1151617289@eng-12.pathscale.com>
From: Bryan O'Sullivan <bos@pathscale.com>
Date: Thu, 29 Jun 2006 14:41:29 -0700
> ipath_core-$(CONFIG_X86_64) += ipath_wc_x86_64.o
> +ipath_core-$(CONFIG_PPC64) += ipath_wc_ppc64.o
Again, don't put these kinds of cpu specific functions
into the infiniband driver. They are potentially globally
useful, not something only Infiniband might want to do.
^ permalink raw reply
* Re: [PATCH 39 of 39] IB/ipath - use streaming copy in RDMA interrupt handler to reduce packet loss
From: Bryan O'Sullivan @ 2006-06-29 21:59 UTC (permalink / raw)
To: David Miller; +Cc: akpm, rdreier, mst, openib-general, linux-kernel, netdev
In-Reply-To: <20060629.145027.41636491.davem@davemloft.net>
On Thu, 2006-06-29 at 14:50 -0700, David Miller wrote:
> A facility like this doesn't belong in some arbitrary driver layer.
> It belongs as a generic facility the whole kernel could make use
> of.
It could, indeed. In fact, we had that discussion here before I sent
this patch in. It presumably wants to live in lib/, and acquire a more
generic name. What name will capture the uncached-read-but-cached-write
semantics in a useful fashion? memcpy_nc?
<b
^ permalink raw reply
* Re: [PATCH 38 of 39] IB/ipath - More changes to support InfiniPath on PowerPC 970 systems
From: Bryan O'Sullivan @ 2006-06-29 22:01 UTC (permalink / raw)
To: David Miller; +Cc: akpm, rdreier, mst, openib-general, linux-kernel, netdev
In-Reply-To: <20060629.145319.71091846.davem@davemloft.net>
On Thu, 2006-06-29 at 14:53 -0700, David Miller wrote:
> From: Bryan O'Sullivan <bos@pathscale.com>
> Date: Thu, 29 Jun 2006 14:41:29 -0700
>
> > ipath_core-$(CONFIG_X86_64) += ipath_wc_x86_64.o
> > +ipath_core-$(CONFIG_PPC64) += ipath_wc_ppc64.o
>
> Again, don't put these kinds of cpu specific functions
> into the infiniband driver. They are potentially globally
> useful, not something only Infiniband might want to do.
The support for write combining in the kernel is not in a state where
that makes any sense at the moment. Also, this is a single-statement
function.
<b
^ permalink raw reply
* Re: [PATCH 39 of 39] IB/ipath - use streaming copy in RDMA interrupt handler to reduce packet loss
From: David Miller @ 2006-06-29 22:03 UTC (permalink / raw)
To: bos; +Cc: akpm, rdreier, mst, openib-general, linux-kernel, netdev
In-Reply-To: <1151618377.10886.23.camel@chalcedony.pathscale.com>
From: Bryan O'Sullivan <bos@pathscale.com>
Date: Thu, 29 Jun 2006 14:59:37 -0700
> It could, indeed. In fact, we had that discussion here before I sent
> this patch in. It presumably wants to live in lib/, and acquire a more
> generic name. What name will capture the uncached-read-but-cached-write
> semantics in a useful fashion? memcpy_nc?
I'm not good with names :-)
Note that there also might be cases where using such a memcpy
variant might be the wrong thing to do. For example, for a very
tightly coupled CMT cpu implementation which has the memory controller,
L2 cache, PCI controller, etc. all on the same die and the PCI controller
makes use of the L2 cache just like the cpu threads do, using this
kind of memcpy would always be the wrong thing to do.
^ permalink raw reply
* Re: [PATCH 38 of 39] IB/ipath - More changes to support InfiniPath on PowerPC 970 systems
From: David Miller @ 2006-06-29 22:04 UTC (permalink / raw)
To: bos; +Cc: akpm, rdreier, mst, openib-general, linux-kernel, netdev
In-Reply-To: <1151618499.10886.26.camel@chalcedony.pathscale.com>
From: Bryan O'Sullivan <bos@pathscale.com>
Date: Thu, 29 Jun 2006 15:01:39 -0700
> The support for write combining in the kernel is not in a state where
> that makes any sense at the moment.
Please fix the generic code if it doesn't provide the facility
you need at the moment. Don't shoe horn it into your driver
just to make up for that.
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: Shailabh Nagar @ 2006-06-29 22:13 UTC (permalink / raw)
To: Andrew Morton
Cc: pj, Valdis.Kletnieks, jlan, balbir, csturtiv, linux-kernel, hadi,
netdev
In-Reply-To: <20060629130046.c695c6c5.akpm@osdl.org>
Andrew Morton wrote:
>>Yup...the per-cpu, high speed requirements are up relayfs' alley, unless
>>Jamal or netlink folks
>>are planning something (or can shed light on) how large flows can be
>>managed over netlink. I suspect
>>this discussion has happened before :-)
>
>
> yeah.
And now I remember why I didn't go down that path earlier. Relayfs is one-way
kernel->user and lacks the ability to send query commands from user space
that we need. Either we would need to send commands up through a separate interface
(even a syscall) or try and ensure that the exiting genetlink interface can
scale better with message volume (including throttling).
--Shailabh
^ permalink raw reply
* strict isolation of net interfaces
From: Cedric Le Goater @ 2006-06-29 22:14 UTC (permalink / raw)
To: Sam Vilain
Cc: hadi, Herbert Poetzl, Alexey Kuznetsov, viro, devel, dev,
Andrew Morton, serue, netdev, linux-kernel, Andrey Savochkin,
Daniel Lezcano, Ben Greear, Dave Hansen, Alexey Kuznetsov,
Eric W. Biederman
In-Reply-To: <44A44124.5010602@vilain.net>
Sam Vilain wrote:
> jamal wrote:
>>> note: personally I'm absolutely not against virtualizing
>>> the device names so that each guest can have a separate
>>> name space for devices, but there should be a way to
>>> 'see' _and_ 'identify' the interfaces from outside
>>> (i.e. host or spectator context)
>>>
>>>
>> Makes sense for the host side to have naming convention tied
>> to the guest. Example as a prefix: guest0-eth0. Would it not
>> be interesting to have the host also manage these interfaces
>> via standard tools like ip or ifconfig etc? i.e if i admin up
>> guest0-eth0, then the user in guest0 will see its eth0 going
>> up.
>
> That particular convention only works if you have network namespaces and
> UTS namespaces tightly bound. We plan to have them separate - so for
> that to work, each network namespace could have an arbitrary "prefix"
> that determines what the interface name will look like from the outside
> when combined. We'd have to be careful about length limits.
>
> And guest0-eth0 doesn't necessarily make sense; it's not really an
> ethernet interface, more like a tun or something.
>
> So, an equally good convention might be to use sequential prefixes on
> the host, like "tun", "dummy", or a new prefix - then a property of that
> is what the name of the interface is perceived to be to those who are in
> the corresponding network namespace.
>
> Then the pragmatic question becomes how to correlate what you see from
> `ip addr list' to guests.
we could work on virtualizing the net interfaces in the host, map them to
eth0 or something in the guest and let the guest handle upper network layers ?
lo0 would just be exposed relying on skbuff tagging to discriminate traffic
between guests.
host | guest 0 | guest 1 | guest2
----------------------+-----------+-----------+--------------
| | | |
|-> l0 <-------+-> lo0 ... | lo0 | lo0
| | | |
|-> bar0 <--------+-> eth0 | |
| | | |
|-> foo0 <--------+-----------+-----------+-> eth0
| | | |
`-> foo0:1 <-------+-----------+-> eth0 |
| | |
is that clear ? stupid ? reinventing the wheel ?
thanks,
C.
^ permalink raw reply
* [PATCH 2.6.17] support for TSO over IPv6
From: Ananda Raju @ 2006-06-29 22:18 UTC (permalink / raw)
To: netdev, jgarzik, shemminger
Cc: Leonid.Grossman, Ravinandan.Arakali, Ananda.Raju,
sivakumar.subramani, Sriram.Rapuru
Hi,
This patch enables TSO over IPv6. Currently Linux network stacks
restricts TSO over IPv6 by clearing of the NETIF_F_TSO bit from
"dev->features". This patch will remove this restriction.
This patch will introduce a new flag NETIF_F_TSO6 which will be used
to check whether device supports TSO over IPv6. If device support TSO
over IPv6 then we don't clear of NETIF_F_TSO and which will make the
TCP layer to create TSO packets. Any device supporting TSO over IPv6
will set NETIF_F_TSO6 flag in "dev->features" along with NETIF_F_TSO.
In case when user disables TSO using ethtool, NETIF_F_TSO will get
cleared from "dev->features". So even if we have NETIF_F_TSO6 we don't
get TSO packets created by TCP layer.
SKB_GSO_TCPV4 renamed to SKB_GSO_TCP to make it generic GSO packet.
SKB_GSO_UDPV4 renamed to SKB_GSO_UDP as UFO is not a IPv4 feature.
UFO is supported over IPv6 also
The following table shows there is significant improvement in
throughput with normal frames and CPU usage for both normal and jumbo.
--------------------------------------------------
| | 1500 | 9600 |
| ------------------|-------------------|
| | thru CPU | thru CPU |
--------------------------------------------------
| TSO OFF | 2.00 5.5% id | 5.66 20.0% id |
--------------------------------------------------
| TSO ON | 2.63 78.0 id | 5.67 39.0% id |
--------------------------------------------------
Please review the patch.
Signed-off-by: Ananda Raju <ananda.raju@neterion.com>
---
diff -upNr netdev.org/drivers/net/s2io.c netdev.ipv6_tso/drivers/net/s2io.c
--- netdev.org/drivers/net/s2io.c 2006-06-27 07:30:36.000000000 -0700
+++ netdev.ipv6_tso/drivers/net/s2io.c 2006-06-27 07:38:48.000000000 -0700
@@ -3960,7 +3960,7 @@ static int s2io_xmit(struct sk_buff *skb
txdp->Control_2 = 0;
#ifdef NETIF_F_TSO
mss = skb_shinfo(skb)->gso_size;
- if (skb_shinfo(skb)->gso_type == SKB_GSO_TCPV4) {
+ if (skb_shinfo(skb)->gso_type == SKB_GSO_TCP) {
txdp->Control_1 |= TXD_TCP_LSO_EN;
txdp->Control_1 |= TXD_TCP_LSO_MSS(mss);
}
@@ -3980,7 +3980,7 @@ static int s2io_xmit(struct sk_buff *skb
}
frg_len = skb->len - skb->data_len;
- if (skb_shinfo(skb)->gso_type == SKB_GSO_UDPV4) {
+ if (skb_shinfo(skb)->gso_type == SKB_GSO_UDP) {
int ufo_size;
ufo_size = skb_shinfo(skb)->gso_size;
@@ -4009,7 +4009,7 @@ static int s2io_xmit(struct sk_buff *skb
txdp->Host_Control = (unsigned long) skb;
txdp->Control_1 |= TXD_BUFFER0_SIZE(frg_len);
- if (skb_shinfo(skb)->gso_type == SKB_GSO_UDPV4)
+ if (skb_shinfo(skb)->gso_type == SKB_GSO_UDP)
txdp->Control_1 |= TXD_UFO_EN;
frg_cnt = skb_shinfo(skb)->nr_frags;
@@ -4024,12 +4024,12 @@ static int s2io_xmit(struct sk_buff *skb
(sp->pdev, frag->page, frag->page_offset,
frag->size, PCI_DMA_TODEVICE);
txdp->Control_1 = TXD_BUFFER0_SIZE(frag->size);
- if (skb_shinfo(skb)->gso_type == SKB_GSO_UDPV4)
+ if (skb_shinfo(skb)->gso_type == SKB_GSO_UDP)
txdp->Control_1 |= TXD_UFO_EN;
}
txdp->Control_1 |= TXD_GATHER_CODE_LAST;
- if (skb_shinfo(skb)->gso_type == SKB_GSO_UDPV4)
+ if (skb_shinfo(skb)->gso_type == SKB_GSO_UDP)
frg_cnt++; /* as Txd0 was used for inband header */
tx_fifo = mac_control->tx_FIFO_start[queue];
@@ -4043,7 +4043,7 @@ static int s2io_xmit(struct sk_buff *skb
if (mss)
val64 |= TX_FIFO_SPECIAL_FUNC;
#endif
- if (skb_shinfo(skb)->gso_type == SKB_GSO_UDPV4)
+ if (skb_shinfo(skb)->gso_type == SKB_GSO_UDP)
val64 |= TX_FIFO_SPECIAL_FUNC;
writeq(val64, &tx_fifo->List_Control);
@@ -7021,6 +7021,9 @@ s2io_init_nic(struct pci_dev *pdev, cons
#ifdef NETIF_F_TSO
dev->features |= NETIF_F_TSO;
#endif
+#ifdef NETIF_F_TSO6
+ dev->features |= NETIF_F_TSO6;
+#endif
if (sp->device_type & XFRAME_II_DEVICE) {
dev->features |= NETIF_F_UFO;
dev->features |= NETIF_F_HW_CSUM;
diff -upNr netdev.org/include/linux/netdevice.h netdev.ipv6_tso/include/linux/netdevice.h
--- netdev.org/include/linux/netdevice.h 2006-06-27 07:30:36.000000000 -0700
+++ netdev.ipv6_tso/include/linux/netdevice.h 2006-06-27 07:38:48.000000000 -0700
@@ -313,8 +313,9 @@ struct net_device
/* Segmentation offload features */
#define NETIF_F_GSO_SHIFT 16
-#define NETIF_F_TSO (SKB_GSO_TCPV4 << NETIF_F_GSO_SHIFT)
-#define NETIF_F_UFO (SKB_GSO_UDPV4 << NETIF_F_GSO_SHIFT)
+#define NETIF_F_TSO (SKB_GSO_TCP << NETIF_F_GSO_SHIFT)
+#define NETIF_F_UFO (SKB_GSO_UDP << NETIF_F_GSO_SHIFT)
+#define NETIF_F_TSO6 (SKB_GSO_TCPV6 << NETIF_F_GSO_SHIFT)
#define NETIF_F_GEN_CSUM (NETIF_F_NO_CSUM | NETIF_F_HW_CSUM)
#define NETIF_F_ALL_CSUM (NETIF_F_IP_CSUM | NETIF_F_GEN_CSUM)
diff -upNr netdev.org/include/linux/skbuff.h netdev.ipv6_tso/include/linux/skbuff.h
--- netdev.org/include/linux/skbuff.h 2006-06-27 07:30:36.000000000 -0700
+++ netdev.ipv6_tso/include/linux/skbuff.h 2006-06-27 07:38:48.000000000 -0700
@@ -170,8 +170,9 @@ enum {
};
enum {
- SKB_GSO_TCPV4 = 1 << 0,
- SKB_GSO_UDPV4 = 1 << 1,
+ SKB_GSO_TCP = 1 << 0,
+ SKB_GSO_UDP = 1 << 1,
+ SKB_GSO_TCPV6 = 1 << 2,
};
/**
diff -upNr netdev.org/net/ipv4/ip_output.c netdev.ipv6_tso/net/ipv4/ip_output.c
--- netdev.org/net/ipv4/ip_output.c 2006-06-27 07:30:36.000000000 -0700
+++ netdev.ipv6_tso/net/ipv4/ip_output.c 2006-06-27 07:38:48.000000000 -0700
@@ -744,7 +744,7 @@ static inline int ip_ufo_append_data(str
if (!err) {
/* specify the length of each IP datagram fragment*/
skb_shinfo(skb)->gso_size = mtu - fragheaderlen;
- skb_shinfo(skb)->gso_type = SKB_GSO_UDPV4;
+ skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
__skb_queue_tail(&sk->sk_write_queue, skb);
return 0;
@@ -1089,7 +1089,7 @@ ssize_t ip_append_page(struct sock *sk,
if ((sk->sk_protocol == IPPROTO_UDP) &&
(rt->u.dst.dev->features & NETIF_F_UFO)) {
skb_shinfo(skb)->gso_size = mtu - fragheaderlen;
- skb_shinfo(skb)->gso_type = SKB_GSO_UDPV4;
+ skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
}
diff -upNr netdev.org/net/ipv4/tcp_output.c netdev.ipv6_tso/net/ipv4/tcp_output.c
--- netdev.org/net/ipv4/tcp_output.c 2006-06-27 07:30:36.000000000 -0700
+++ netdev.ipv6_tso/net/ipv4/tcp_output.c 2006-06-27 07:38:48.000000000 -0700
@@ -525,7 +525,7 @@ static void tcp_set_skb_tso_segs(struct
factor /= mss_now;
skb_shinfo(skb)->gso_segs = factor;
skb_shinfo(skb)->gso_size = mss_now;
- skb_shinfo(skb)->gso_type = SKB_GSO_TCPV4;
+ skb_shinfo(skb)->gso_type = SKB_GSO_TCP;
}
}
diff -upNr netdev.org/net/ipv6/af_inet6.c netdev.ipv6_tso/net/ipv6/af_inet6.c
--- netdev.org/net/ipv6/af_inet6.c 2006-06-27 07:30:36.000000000 -0700
+++ netdev.ipv6_tso/net/ipv6/af_inet6.c 2006-06-27 07:38:48.000000000 -0700
@@ -660,8 +660,11 @@ int inet6_sk_rebuild_header(struct sock
}
ip6_dst_store(sk, dst, NULL);
- sk->sk_route_caps = dst->dev->features &
- ~(NETIF_F_IP_CSUM | NETIF_F_TSO);
+ if (dst->dev->features & NETIF_F_TSO6)
+ sk->sk_route_caps = dst->dev->features;
+ else
+ sk->sk_route_caps = dst->dev->features &
+ ~(NETIF_F_IP_CSUM | NETIF_F_TSO);
}
return 0;
diff -upNr netdev.org/net/ipv6/inet6_connection_sock.c netdev.ipv6_tso/net/ipv6/inet6_connection_sock.c
--- netdev.org/net/ipv6/inet6_connection_sock.c 2006-06-27 07:30:36.000000000 -0700
+++ netdev.ipv6_tso/net/ipv6/inet6_connection_sock.c 2006-06-27 07:38:48.000000000 -0700
@@ -187,8 +187,11 @@ int inet6_csk_xmit(struct sk_buff *skb,
}
ip6_dst_store(sk, dst, NULL);
- sk->sk_route_caps = dst->dev->features &
- ~(NETIF_F_IP_CSUM | NETIF_F_TSO);
+ if (dst->dev->features & NETIF_F_TSO6)
+ sk->sk_route_caps = dst->dev->features;
+ else
+ sk->sk_route_caps = dst->dev->features &
+ ~(NETIF_F_IP_CSUM | NETIF_F_TSO);
}
skb->dst = dst_clone(dst);
diff -upNr netdev.org/net/ipv6/ip6_output.c netdev.ipv6_tso/net/ipv6/ip6_output.c
--- netdev.org/net/ipv6/ip6_output.c 2006-06-27 07:30:36.000000000 -0700
+++ netdev.ipv6_tso/net/ipv6/ip6_output.c 2006-06-27 07:38:48.000000000 -0700
@@ -230,7 +230,7 @@ int ip6_xmit(struct sock *sk, struct sk_
skb->priority = sk->sk_priority;
mtu = dst_mtu(dst);
- if ((skb->len <= mtu) || ipfragok) {
+ if ((skb->len <= mtu) || ipfragok || skb_shinfo(skb)->gso_size) {
IP6_INC_STATS(IPSTATS_MIB_OUTREQUESTS);
return NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, dst->dev,
dst_output);
@@ -835,7 +835,7 @@ static inline int ip6_ufo_append_data(st
/* specify the length of each IP datagram fragment*/
skb_shinfo(skb)->gso_size = mtu - fragheaderlen -
sizeof(struct frag_hdr);
- skb_shinfo(skb)->gso_type = SKB_GSO_UDPV4;
+ skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
ipv6_select_ident(skb, &fhdr);
skb_shinfo(skb)->ip6_frag_id = fhdr.identification;
__skb_queue_tail(&sk->sk_write_queue, skb);
diff -upNr netdev.org/net/ipv6/tcp_ipv6.c netdev.ipv6_tso/net/ipv6/tcp_ipv6.c
--- netdev.org/net/ipv6/tcp_ipv6.c 2006-06-27 07:30:36.000000000 -0700
+++ netdev.ipv6_tso/net/ipv6/tcp_ipv6.c 2006-06-27 07:38:48.000000000 -0700
@@ -271,8 +271,11 @@ static int tcp_v6_connect(struct sock *s
inet->rcv_saddr = LOOPBACK4_IPV6;
ip6_dst_store(sk, dst, NULL);
- sk->sk_route_caps = dst->dev->features &
- ~(NETIF_F_IP_CSUM | NETIF_F_TSO);
+ if (dst->dev->features & NETIF_F_TSO6)
+ sk->sk_route_caps = dst->dev->features;
+ else
+ sk->sk_route_caps = dst->dev->features &
+ ~(NETIF_F_IP_CSUM | NETIF_F_TSO);
icsk->icsk_ext_hdr_len = 0;
if (np->opt)
@@ -931,8 +934,11 @@ static struct sock * tcp_v6_syn_recv_soc
*/
ip6_dst_store(newsk, dst, NULL);
- newsk->sk_route_caps = dst->dev->features &
- ~(NETIF_F_IP_CSUM | NETIF_F_TSO);
+ if (dst->dev->features & NETIF_F_TSO6)
+ sk->sk_route_caps = dst->dev->features;
+ else
+ newsk->sk_route_caps = dst->dev->features &
+ ~(NETIF_F_IP_CSUM | NETIF_F_TSO);
newtcp6sk = (struct tcp6_sock *)newsk;
inet_sk(newsk)->pinet6 = &newtcp6sk->inet6;
^ permalink raw reply
* Re: [PATCH 8/9] pcnet32: NAPI implementation.
From: Francois Romieu @ 2006-06-29 22:24 UTC (permalink / raw)
To: Don Fry; +Cc: tsbogend, jgarzik, netdev
In-Reply-To: <20060629205551.GA22031@us.ibm.com>
Nit below.
Don Fry <brazilnut@us.ibm.com> :
[...]
> --- linux-2.6.17-git13/drivers/net/purge.pcnet32.c Thu Jun 29 13:28:24 2006
> +++ linux-2.6.17-git13/drivers/net/pcnet32.c Thu Jun 29 13:28:31 2006
[...]
> +#ifdef CONFIG_PCNET32_NAPI
> +static int pcnet32_poll(struct net_device *dev, int *budget)
> +{
[...]
> + netif_rx_complete(dev);
> +
> + spin_lock_irqsave(&lp->lock, flags);
No need to save/restore (it's true in pcnet32_{get_regs/suspend} too).
> +
> + /* clear interrupt masks */
> + val = lp->a.read_csr(ioaddr, CSR3);
> + val &= 0x00ff;
> + lp->a.write_csr(ioaddr, CSR3, val);
> +
> + /* Set interrupt enable. */
> + lp->a.write_csr(ioaddr, CSR0, CSR0_INTEN);
Insert mmiowb():
> +
> + spin_unlock_irqrestore(&lp->lock, flags);
[...]
> @@ -2413,183 +2608,41 @@ pcnet32_interrupt(int irq, void *dev_id,
> dev->name, csr0);
> /* unlike for the lance, there is no restart needed */
> }
> -
> - if (must_restart) {
> +#ifdef CONFIG_PCNET32_NAPI
> + if (netif_rx_schedule_prep(dev)) {
> + u16 val;
> + /* set interrupt masks */
> + val = lp->a.read_csr(ioaddr, CSR3);
> + val |= 0x5f00;
> + lp->a.write_csr(ioaddr, CSR3, val);
Insert mmiowb();
--
Ueimor
^ permalink raw reply
* Re: [PATCH 2.6.17] support for TSO over IPv6
From: David Miller @ 2006-06-29 22:30 UTC (permalink / raw)
To: Ananda.Raju
Cc: netdev, jgarzik, shemminger, Leonid.Grossman, Ravinandan.Arakali,
sivakumar.subramani, Sriram.Rapuru
In-Reply-To: <Pine.GSO.4.10.10606291810490.12773-100000@guinness>
From: Ananda Raju <Ananda.Raju@neterion.com>
Date: Thu, 29 Jun 2006 18:18:10 -0400 (EDT)
> This patch enables TSO over IPv6. Currently Linux network stacks
> restricts TSO over IPv6 by clearing of the NETIF_F_TSO bit from
> "dev->features". This patch will remove this restriction.
Generally this looks very good.
Since Herbert Xu has been playing a bit in this area, I'd like
to hear some feedback from him before I apply this.
^ permalink raw reply
* Re: 2.6.17.1: fails to fully get webpage
From: CaT @ 2006-06-29 22:50 UTC (permalink / raw)
To: Bill Davidsen; +Cc: linux-kernel, netdev
In-Reply-To: <44A3E898.1020202@tmr.com>
On Thu, Jun 29, 2006 at 10:50:00AM -0400, Bill Davidsen wrote:
> >Basically the mostlikely end-result is I don't know what there is a
> >problem and my customer doesn't know that there is a problem but they're
> >just not getting as many hits to their site that they otherwise would.
> >
> >Ofcourse, this all depends if such a situation is possible. If it is
> >possible would it affect dns and mail in a similar manner too?
> >
> I'm glad David Miller clarified this, because I was about to send a
> "don't do that" followup ;-)
:) I don't know how I got the wrong config option to modify but there
you go. :)
> But your example is misleading, or at least doesn't reflect customers I
> know. While a few clients with broken network connections may be
> unhappy, disabling scaling will make your web server really, really,
> slow, and that will make everyone unhappy. Particularly if the web
> content is flash or 2MB jpegs, or other ill-chosen stuff. You don't want
> people to think you are running at dial-up speeds.
Which would be why I wont move from 2.6.16.x for my servers unless I
really, really, really have to. I don't know how many broken sites are
out there and I cannot tell.
Another datapoint to this is that I've had this my netcat web test
running since 8:42pm yesterday. It's 8:37am now. It hasn't progressed
in any way. It hasn't quit. It hasn't timed out. It just sits there,
hung. This leads me to consider the possibility of a DOS, either
intentional or accidental (think about 2.6.17.x running on a mail server
and someone mails/spams from a broken place).
--
"To the extent that we overreact, we proffer the terrorists the
greatest tribute."
- High Court Judge Michael Kirby
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: jamal @ 2006-06-29 22:54 UTC (permalink / raw)
To: Shailabh Nagar
Cc: Andrew Morton, pj, Valdis.Kletnieks, jlan, balbir, csturtiv,
linux-kernel, netdev
In-Reply-To: <44A43187.3090307@watson.ibm.com>
On Thu, 2006-29-06 at 16:01 -0400, Shailabh Nagar wrote:
>
> Jamal,
> any thoughts on the flow control capabilities of netlink that apply here
> ? Usage of the connection is to supply statistics data to userspace.
>
if you want reliable delivery, then you cant just depend on async events
from the kernel -> user - which i am assuming is the way stats get
delivered as processes exit? Sorry, i dont remember the details. You
need some synchronous scheme to ask the kernel to do a "get" or "dump".
Lets be clear about one thing:
The problem really has nothing to do with gen/netlink or any other
scheme you use;->
It has everything to do with reliability implications and the fact
that you need to assume memory is a finite resource - at one point
or another you will run out of memory ;-> And of course then messages
will be lost. So for gen/netlink, just make sure you have large socket
buffer and you would most likely be fine.
I havent seen how the numbers were reached: But if you say you receive
14K exits/sec each of which is a 50B message, I would think a 1M socket
buffer would be plenty.
You can find out about lack of memory in netlink when you get a ENOBUFS.
As an example, you should then do a kernel query. Clearly if you do a
query of that sort, you may not want to find obsolete info. Therefore,
as a suggestion, you may want to keep sequence numbers of sorts as
markers. Perhaps keep a 32-bit field which monotically increases per
process exit or use the pid as the sequence number etc..
As for throttling - Shailabh, I think we talked about this:
- You could maintain info using some thresholds and timer. Then
when a timer expires or threshold is exceeded send to user space.
BTW, where is the doc fixes ? ;->
cheers,
jamal
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: jamal @ 2006-06-29 23:00 UTC (permalink / raw)
To: Shailabh Nagar
Cc: Andrew Morton, pj, Valdis.Kletnieks, jlan, balbir, csturtiv,
linux-kernel, netdev
In-Reply-To: <44A450A1.4090202@watson.ibm.com>
On Thu, 2006-29-06 at 18:13 -0400, Shailabh Nagar wrote:
>
> And now I remember why I didn't go down that path earlier. Relayfs is one-way
> kernel->user and lacks the ability to send query commands from user space
> that we need. Either we would need to send commands up through a separate interface
> (even a syscall) or try and ensure that the exiting genetlink interface can
> scale better with message volume (including throttling).
Refer to my other email - whatever it takes to store "bulk" data in the
kernel is subject to the constraint of the fact memory is finite.
You can send messages from the kernel in sizes constrained by the memory
socket size. You can tune the socket size.
cheers,
jamal
^ permalink raw reply
* Re: 2.6.17-mm4
From: Ingo Molnar @ 2006-06-29 23:05 UTC (permalink / raw)
To: Dave Jones, Michal Piotrowski, Andrew Morton, linux-kernel,
netdev; +Cc: Alan Cox
In-Reply-To: <20060629210950.GA300@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
> i'm too hunting use-after-free bugs - the ones fixed below fix certain
> crashes, but i'm still seeing a nasty one.
>
> the crash is independent on lockdep enabled or disabled. See:
>
> http://redhat.com/~mingo/misc/
>
> for the config and the crash.log.
ok, managed to debug the reason for this crash via .config bisecting,
it's caused by:
CONFIG_SCSI_PATA_QDI=y
which is a new option in -mm4. Disabling it makes the -mm4 allyesconfig
bzImage work again.
and running qdi_init() either causes memory corruption, or it causes
something to be misprogrammed on the motherboard (something wrt. irq
routing perhaps), which crashes the box afterwards. (but that happens
dozens of initcalls later, so the breakage is subtle)
it does things like:
static const unsigned long qd_port[2] = { 0x30, 0xB0 };
static const unsigned long ide_port[2] = { 0x170, 0x1F0 };
[...]
unsigned long port = qd_port[i];
[...]
r = inb_p(port);
outb_p(0x19, port);
res = inb_p(port);
outb_p(r, port);
so it reads/writes port 0x30 and 0xb0. Are those used by something else
on modern hardware?
i know, i shouldnt be running an ancient Vesa Local Bus driver's init
routine, but still, the allyesconfig bzImage is quite useful in finding
various bugs ...
Ingo
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: jamal @ 2006-06-29 23:23 UTC (permalink / raw)
To: Thomas Graf; +Cc: Patrick McHardy, David Miller, netdev
In-Reply-To: <20060629085111.GY1376@postel.suug.ch>
I noticed the other email carrying a patch. Let me respond to this email
and hopefully that will address the patch.
On Thu, 2006-29-06 at 10:51 +0200, Thomas Graf wrote:
> * jamal <hadi@cyberus.ca> 2006-06-28 09:46
[..]
> I disagree, iflink information is bogus once we start redirecting.
After redirecting, iflink is "available" i.e it doesnt make any
more sense and therefore it should be (ab)usable to carry other info.
But the more i think about it, using skb->dev is just fine for
finding the device you are looking for even when it gets redirected.
I am assuming you still want to find out - in the case of a topology
which constitutes more than one netdevice - the second last netdevice,
correct?
> >
> > Can you achieve the same by binding to any arbitrary netdevice? If you
> > can then i would agree.
>
> It was your request to not update input_dev in netif_receive_skb()
> but rather have each netdevice handle it manually.
For good reasons of course.
note: you didnt answer the question i asked, but probably the answer
doesnt matter.
> What's currently
> done in ifb:
>
> skb->dev = skb->input_dev;
> skb->input_dev = dev;
>
> Confusing, isn't it?
not at all. Let me explain the design intent further below.
> I really don't get input_dev/iif is supposed to
> be updated in ifb. If a packet is to be redirected, the mirred action
> shall take care of providing this information to the next netdevice.
ifb is a special purpose device.
Think of it as a redirector, or injector if you want a better noun. If
you are going to inject packets back to the stack at arbitrary points,
then you need to reflect that in the packet metadata implying where it
came from. Likewise if you are going to redirect packets into arbitrary
points in the stack (as mirred does), you need to do the same.
I dont know if that makes sense.
> My additional request is to provide a flag to disable this for special
> purposes not hurting anyone.
I am failing to see the purpose.
With all due respect, you are changing the design intent, Thomas.
I know your intent is noble in trying to save the 32 bits on 64 bit
machines (at least thats where your patch seems to have started) but the
cost:benefit ratio as i have pointed out is unreasonable.
If you can meet the requirements i have specified (I am leaving them
below) i will be a happy camper.
> > The challenge is this, and if you can solve it we would be fine:
> > - I need to access both the input_dev and dev and their metadata.
> > I could clearly find them by their ifindices and then reference them
> > after that. For performance reasons that is not optimal in the fast
> > path.
>
So just we are clear: I have strong desire to save compute rather than
than saving 32 bits per skb on 64 bit machine.
> Nice, you forget that while redirecting the device pointed to by
> input_dev can disappear leaving behind an illegal reference.
We have had this discussion before - that is resolvable via
dev_put/hold.
> The purpose of this patch is to fix this.
Appreciated - but can you do it without replacing the input_dev?
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 2.6.17] support for TSO over IPv6
From: Herbert Xu @ 2006-06-29 23:32 UTC (permalink / raw)
To: Ananda Raju
Cc: netdev, jgarzik, shemminger, Leonid.Grossman, Ravinandan.Arakali,
Ananda.Raju, sivakumar.subramani, Sriram.Rapuru
In-Reply-To: <Pine.GSO.4.10.10606291810490.12773-100000@guinness>
Ananda Raju <Ananda.Raju@neterion.com> wrote:
> This patch enables TSO over IPv6. Currently Linux network stacks
> restricts TSO over IPv6 by clearing of the NETIF_F_TSO bit from
> "dev->features". This patch will remove this restriction.
Thanks, looks good over all.
> SKB_GSO_TCPV4 renamed to SKB_GSO_TCP to make it generic GSO packet.
> SKB_GSO_UDPV4 renamed to SKB_GSO_UDP as UFO is not a IPv4 feature.
> UFO is supported over IPv6 also
This bit is wrong though. TCPv4 and TCPv6 packets can't share the same
GSO feature bit. The reason is that GSO/TSO is no longer just activated
by dev->features. Bridges can forward GSO/TSO packets through at any time.
This is why it is crucial that each packet specficies exactly the features
that it requires from the hardware.
For UFO, it's OK to have just SKB_GSO_UDP since IIRC your card is the only
one that supports it and it supports both protocols anyway.
> diff -upNr netdev.org/include/linux/skbuff.h netdev.ipv6_tso/include/linux/skbuff.h
> --- netdev.org/include/linux/skbuff.h 2006-06-27 07:30:36.000000000 -0700
> +++ netdev.ipv6_tso/include/linux/skbuff.h 2006-06-27 07:38:48.000000000 -0700
> @@ -170,8 +170,9 @@ enum {
> };
>
> enum {
> - SKB_GSO_TCPV4 = 1 << 0,
> - SKB_GSO_UDPV4 = 1 << 1,
> + SKB_GSO_TCP = 1 << 0,
> + SKB_GSO_UDP = 1 << 1,
> + SKB_GSO_TCPV6 = 1 << 2,
> };
BTW, you should rediff against Dave's current tree which has a few
extra bits there.
You should also leave TCPV4 as is and just add the TCPV6 bit.
> diff -upNr netdev.org/net/ipv4/tcp_output.c netdev.ipv6_tso/net/ipv4/tcp_output.c
> --- netdev.org/net/ipv4/tcp_output.c 2006-06-27 07:30:36.000000000 -0700
> +++ netdev.ipv6_tso/net/ipv4/tcp_output.c 2006-06-27 07:38:48.000000000 -0700
> @@ -525,7 +525,7 @@ static void tcp_set_skb_tso_segs(struct
> factor /= mss_now;
> skb_shinfo(skb)->gso_segs = factor;
> skb_shinfo(skb)->gso_size = mss_now;
> - skb_shinfo(skb)->gso_type = SKB_GSO_TCPV4;
> + skb_shinfo(skb)->gso_type = SKB_GSO_TCP;
You need to set SKB_GSO_TCPV6 for IPv6 packets here.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 39 of 39] IB/ipath - use streaming copy in RDMA interrupt handler to reduce packet loss
From: Bryan O'Sullivan @ 2006-06-29 23:34 UTC (permalink / raw)
To: David Miller; +Cc: akpm, rdreier, mst, openib-general, linux-kernel, netdev
In-Reply-To: <20060629.150319.104035601.davem@davemloft.net>
On Thu, 2006-06-29 at 15:03 -0700, David Miller wrote:
> I'm not good with names :-)
Heh. I'll call it memcpy_nc for now, then, and people can retch all
over the name as they please when I submit a more suitably generic
patch.
> Note that there also might be cases where using such a memcpy
> variant might be the wrong thing to do. For example, for a very
> tightly coupled CMT cpu implementation which has the memory controller,
> L2 cache, PCI controller, etc. all on the same die and the PCI controller
> makes use of the L2 cache just like the cpu threads do, using this
> kind of memcpy would always be the wrong thing to do.
I'm not quite following you, though I assume you're referring to Niagara
or Rock :-) Are you saying a memcpy_nc would do worse than plain
memcpy, or worse than some other memcpy-like routine?
<b
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: Thomas Graf @ 2006-06-29 23:39 UTC (permalink / raw)
To: jamal; +Cc: Patrick McHardy, David Miller, netdev
In-Reply-To: <1151623394.8922.27.camel@jzny2>
* jamal <hadi@cyberus.ca> 2006-06-29 19:23
> > What's currently
> > done in ifb:
> >
> > skb->dev = skb->input_dev;
> > skb->input_dev = dev;
> >
> > Confusing, isn't it?
>
> not at all. Let me explain the design intent further below.
Then let me show you what your code does:
[mirred attached to filter on eth0 redirecting to ifb0]
tcf_mirred(): skb2->input_dev = skb->dev; (skb2->input_dev=eth0)
ifb_xmit(): skb->dev = skb->input_dev; (skb->dev=eth0)
skb->input_dev = dev; (skb->input_dev=ifb0)
So when reentering the stack the skb looks like it would be
on eth0 coming from ifb0. Is that what you wanted? Shouldn't
it be skb->dev=ifb0 skb->input_dev=eth0? That's what my patch
would change it to.
> I know your intent is noble in trying to save the 32 bits on 64 bit
> machines (at least thats where your patch seems to have started) but the
> cost:benefit ratio as i have pointed out is unreasonable.
Did I ever claim this? You made this up right now. As of now
it doesn't save a single bit.
^ permalink raw reply
* Re: [PATCH 8/9] pcnet32: NAPI implementation.
From: Don Fry @ 2006-06-29 23:41 UTC (permalink / raw)
To: Francois Romieu; +Cc: tsbogend, jgarzik, netdev
In-Reply-To: <20060629222438.GB8122@electric-eye.fr.zoreil.com>
On Fri, Jun 30, 2006 at 12:24:38AM +0200, Francois Romieu wrote:
> Nit below.
>
> Don Fry <brazilnut@us.ibm.com> :
> [...]
> > --- linux-2.6.17-git13/drivers/net/purge.pcnet32.c Thu Jun 29 13:28:24 2006
> > +++ linux-2.6.17-git13/drivers/net/pcnet32.c Thu Jun 29 13:28:31 2006
> [...]
> > +#ifdef CONFIG_PCNET32_NAPI
> > +static int pcnet32_poll(struct net_device *dev, int *budget)
> > +{
> [...]
> > + netif_rx_complete(dev);
> > +
> > + spin_lock_irqsave(&lp->lock, flags);
>
> No need to save/restore (it's true in pcnet32_{get_regs/suspend} too).
This lock is taken by the interrupt handler and my reading of
spinlocks.txt says I do need to use spin_lock_irqsave unless I
misunderstand. The only spin_lock() is in the interrupt handler itself,
all others are spin_lock_irqsave.
>
> > +
> > + /* clear interrupt masks */
> > + val = lp->a.read_csr(ioaddr, CSR3);
> > + val &= 0x00ff;
> > + lp->a.write_csr(ioaddr, CSR3, val);
> > +
> > + /* Set interrupt enable. */
> > + lp->a.write_csr(ioaddr, CSR0, CSR0_INTEN);
>
> Insert mmiowb():
Is this required in addition to the two outw() in write_csr? There are
rmb() and wmb() in the places that need them, but no mmiowb() anywhere.
What are the factors for when mmiowb needs to be inserted?
>
> > +
> > + spin_unlock_irqrestore(&lp->lock, flags);
>
> [...]
> > @@ -2413,183 +2608,41 @@ pcnet32_interrupt(int irq, void *dev_id,
> > dev->name, csr0);
> > /* unlike for the lance, there is no restart needed */
> > }
> > -
> > - if (must_restart) {
> > +#ifdef CONFIG_PCNET32_NAPI
> > + if (netif_rx_schedule_prep(dev)) {
> > + u16 val;
> > + /* set interrupt masks */
> > + val = lp->a.read_csr(ioaddr, CSR3);
> > + val |= 0x5f00;
> > + lp->a.write_csr(ioaddr, CSR3, val);
>
> Insert mmiowb();
>
> --
> Ueimor
--
Don Fry
brazilnut@us.ibm.com
^ permalink raw reply
* Re: [PATCH 39 of 39] IB/ipath - use streaming copy in RDMA interrupt handler to reduce packet loss
From: David Miller @ 2006-06-29 23:46 UTC (permalink / raw)
To: bos; +Cc: akpm, rdreier, mst, openib-general, linux-kernel, netdev
In-Reply-To: <1151624063.10886.34.camel@chalcedony.pathscale.com>
From: Bryan O'Sullivan <bos@pathscale.com>
Date: Thu, 29 Jun 2006 16:34:23 -0700
> I'm not quite following you, though I assume you're referring to Niagara
> or Rock :-) Are you saying a memcpy_nc would do worse than plain
> memcpy, or worse than some other memcpy-like routine?
It would do worse than memcpy.
If you bypass the L2 cache, it's pointless because the next
agent (PCI controller, CPU thread, etc.) is going to need the
data in the L2 cache.
It's better in that kind of setup to eat the L2 cache miss overhead in
memcpy since memcpy can usually prefetch and store buffer in order to
absorb some of the L2 miss costs.
^ permalink raw reply
* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: David Miller @ 2006-06-29 23:47 UTC (permalink / raw)
To: tgraf; +Cc: hadi, kaber, netdev
In-Reply-To: <20060629233933.GB14627@postel.suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Fri, 30 Jun 2006 01:39:33 +0200
> * jamal <hadi@cyberus.ca> 2006-06-29 19:23
> > I know your intent is noble in trying to save the 32 bits on 64 bit
> > machines (at least thats where your patch seems to have started) but the
> > cost:benefit ratio as i have pointed out is unreasonable.
>
> Did I ever claim this? You made this up right now. As of now
> it doesn't save a single bit.
Right.
>From what I can see Thomas's work allows to do correct
reference counting on the input_dev, something which is
not possible right now and is a bug.
^ permalink raw reply
* Re: [openib-general] [PATCH 39 of 39] IB/ipath - use streaming copy in RDMA interrupt handler to reduce packet loss
From: Ralph Campbell @ 2006-06-29 23:55 UTC (permalink / raw)
To: David Miller; +Cc: bos, akpm, netdev, rdreier, linux-kernel, openib-general
In-Reply-To: <20060629.164623.59469884.davem@davemloft.net>
This is intended to be an architecture specific function
so if the CPU does support HW dma to the CPU's L2 cache, the
architecture specific version of memcpy_nc() would not replace
the default definition which maps memcpy_nc() to memcpy().
For CPUs like the vast majority currently available, there
is a performance benefit by not reading data into the cache
that won't be read a second time.
On Thu, 2006-06-29 at 16:46 -0700, David Miller wrote:
> From: Bryan O'Sullivan <bos@pathscale.com>
> Date: Thu, 29 Jun 2006 16:34:23 -0700
>
> > I'm not quite following you, though I assume you're referring to Niagara
> > or Rock :-) Are you saying a memcpy_nc would do worse than plain
> > memcpy, or worse than some other memcpy-like routine?
>
> It would do worse than memcpy.
>
> If you bypass the L2 cache, it's pointless because the next
> agent (PCI controller, CPU thread, etc.) is going to need the
> data in the L2 cache.
>
> It's better in that kind of setup to eat the L2 cache miss overhead in
> memcpy since memcpy can usually prefetch and store buffer in order to
> absorb some of the L2 miss costs.
>
> _______________________________________________
> openib-general mailing list
> openib-general@openib.org
> http://openib.org/mailman/listinfo/openib-general
>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>
^ permalink raw reply
* Re: [PATCH 1/2] [IrDA] Fix RCU lock pairing on error path
From: David Miller @ 2006-06-30 0:02 UTC (permalink / raw)
To: samuel-jcdQHdrhKHMdnm+yROfE0A
Cc: akpm-3NddpPZAyC0, josht-DhXWPJtHtuFWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
paulmck-r/Jw6+rmf7HQT0dZR+AlfA,
irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
dipankar-xthvdsQ13ZrQT0dZR+AlfA
In-Reply-To: <20060630065534.GA4729-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
From: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
Date: Fri, 30 Jun 2006 09:55:34 +0300
> irlan_client_discovery_indication calls rcu_read_lock and rcu_read_unlock, but
> returns without unlocking in an error case. Fix that by replacing the return
> with a goto so that the rcu_read_unlock always gets executed.
>
> Signed-off-by: Josh Triplett <josh-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org>
> Acked-by: Paul E. McKenney <paulmck-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Samuel Ortiz samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org <>
Applied, thanks.
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
^ permalink raw reply
* Re: [PATCH 17 of 39] IB/ipath - use more appropriate gfp flags
From: Andrew Morton @ 2006-06-30 0:02 UTC (permalink / raw)
To: Bryan O'Sullivan; +Cc: rdreier, mst, openib-general, linux-kernel, netdev
In-Reply-To: <9d943b828776136a2bb7.1151617268@eng-12.pathscale.com>
"Bryan O'Sullivan" <bos@pathscale.com> wrote:
>
> diff -r fd5e733f02ac -r 9d943b828776 drivers/infiniband/hw/ipath/ipath_file_ops.c
> --- a/drivers/infiniband/hw/ipath/ipath_file_ops.c Thu Jun 29 14:33:25 2006 -0700
> +++ b/drivers/infiniband/hw/ipath/ipath_file_ops.c Thu Jun 29 14:33:25 2006 -0700
> @@ -705,6 +705,15 @@ static int ipath_create_user_egr(struct
> unsigned e, egrcnt, alloced, egrperchunk, chunk, egrsize, egroff;
> size_t size;
> int ret;
> + gfp_t gfp_flags;
> +
> + /*
> + * GFP_USER, but without GFP_FS, so buffer cache can be
> + * coalesced (we hope); otherwise, even at order 4,
> + * heavy filesystem activity makes these fail, and we can
> + * use compound pages.
> + */
> + gfp_flags = __GFP_WAIT | __GFP_IO | __GFP_COMP;
Yes, GFP_NOFS|_GFP_COMP is reasonably strong - we can do swapout but not
file pageout.
I expect you'll find that a full GFP_KERNEL is OK here. The ~__GFP_FS is
used to prevent the vm scanner from calling into ->writepage() and getting
stuck on locks which the __alloc_pages() caller already holds.
But ipathfs doesn't even implement ->writepage(), so I don't see any
problem with setting __GFP_FS. If you're getting into trouble there then
I'd recommend giving it a try - it will make memory reclaim more
successful, especially with ext3, where a ->writepage often cleans the page
synchronously without doing any IO.
That being said, order-4 allocations will be fairly reliably unreliable.
^ permalink raw reply
* Re: [PATCH 2/2] [IrDA] Fix the AU1000 FIR dependencies
From: David Miller @ 2006-06-30 0:03 UTC (permalink / raw)
To: samuel-jcdQHdrhKHMdnm+yROfE0A
Cc: akpm-3NddpPZAyC0, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ralf-6z/3iImG2C8G8FEW9MqTrA,
bunk-HeJ8Db2Gnd6zQB+pC5nmwQ,
irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
reiga-dF3JGIbHi9Ffir3NkZym1w
In-Reply-To: <20060630065607.GB4729-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
From: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
Date: Fri, 30 Jun 2006 09:56:07 +0300
> AU1000 FIR is broken, it should depend on SOC_AU1000.
>
> Spotted by Jean-Luc Leger.
>
> Signed-off-by: Adrian Bunk <bunk-HeJ8Db2Gnd6zQB+pC5nmwQ@public.gmane.org>
> Signed-off-by: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
Applied, thanks.
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox