Re: [PATCH 06/33] mm: allow PF_MEMALLOC from softirq context
On Wed, 2007-10-31 at 21:49 +1100, Nick Piggin wrote: > On Wednesday 31 October 2007 21:42, Peter Zijlstra wrote: > > On Wed, 2007-10-31 at 14:51 +1100, Nick Piggin wrote: > > > On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote: > > > > Allow PF_MEMALLOC to be set in softirq context. When running softirqs > > > > from a borrowed context save current->flags, ksoftirqd will have its > > > > own task_struct. > > > > > > What's this for? Why would ksoftirqd pick up PF_MEMALLOC? (I guess > > > that some networking thing must be picking it up in a subsequent patch, > > > but I'm too lazy to look!)... Again, can you have more of a rationale in > > > your patch headers, or ref the patch that uses it... thanks > > > > Right, I knew I was forgetting something in these changelogs. > > > > The network stack does quite a bit of packet processing from softirq > > context. Once you start swapping over network, some of the packets want > > to be processed under PF_MEMALLOC. > > Hmm... what about processing from interrupt context? From what I could tell that is not done, ISR just fills the skb and sticks it on an RX queue to be further processed by the softirq. signature.asc Description: This is a digitally signed message part
Re: [PATCH 06/33] mm: allow PF_MEMALLOC from softirq context
On Wednesday 31 October 2007 21:42, Peter Zijlstra wrote: > On Wed, 2007-10-31 at 14:51 +1100, Nick Piggin wrote: > > On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote: > > > Allow PF_MEMALLOC to be set in softirq context. When running softirqs > > > from a borrowed context save current->flags, ksoftirqd will have its > > > own task_struct. > > > > What's this for? Why would ksoftirqd pick up PF_MEMALLOC? (I guess > > that some networking thing must be picking it up in a subsequent patch, > > but I'm too lazy to look!)... Again, can you have more of a rationale in > > your patch headers, or ref the patch that uses it... thanks > > Right, I knew I was forgetting something in these changelogs. > > The network stack does quite a bit of packet processing from softirq > context. Once you start swapping over network, some of the packets want > to be processed under PF_MEMALLOC. Hmm... what about processing from interrupt context? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/33] mm: allow PF_MEMALLOC from softirq context
On Wed, 2007-10-31 at 14:51 +1100, Nick Piggin wrote: > On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote: > > Allow PF_MEMALLOC to be set in softirq context. When running softirqs from > > a borrowed context save current->flags, ksoftirqd will have its own > > task_struct. > > > What's this for? Why would ksoftirqd pick up PF_MEMALLOC? (I guess > that some networking thing must be picking it up in a subsequent patch, > but I'm too lazy to look!)... Again, can you have more of a rationale in > your patch headers, or ref the patch that uses it... thanks Right, I knew I was forgetting something in these changelogs. The network stack does quite a bit of packet processing from softirq context. Once you start swapping over network, some of the packets want to be processed under PF_MEMALLOC. See patch 23/33. signature.asc Description: This is a digitally signed message part
Re: [PATCH 06/33] mm: allow PF_MEMALLOC from softirq context
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote: > Allow PF_MEMALLOC to be set in softirq context. When running softirqs from > a borrowed context save current->flags, ksoftirqd will have its own > task_struct. What's this for? Why would ksoftirqd pick up PF_MEMALLOC? (I guess that some networking thing must be picking it up in a subsequent patch, but I'm too lazy to look!)... Again, can you have more of a rationale in your patch headers, or ref the patch that uses it... thanks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
