On Wed, Aug 29, 2012 at 07:24:48AM -0700, Eric Dumazet wrote:
> On Wed, 2012-08-29 at 16:50 +0300, Alexey Dobriyan wrote:
> > On Wed, Aug 29, 2012 at 7:11 AM, Eric Dumazet
> > wrote:
> > > I'll polish this patch once LKS/LPC is over...
> >
> > It should oops in the following way (excuse Gmail pl
On Wed, 2012-08-29 at 16:50 +0300, Alexey Dobriyan wrote:
> On Wed, Aug 29, 2012 at 7:11 AM, Eric Dumazet wrote:
> > I'll polish this patch once LKS/LPC is over...
>
> It should oops in the following way (excuse Gmail please):
> PDEO is removed from lists
> ->pde_users is 0
> PDE won't be in purg
On Wed, Aug 29, 2012 at 7:11 AM, Eric Dumazet wrote:
> I'll polish this patch once LKS/LPC is over...
It should oops in the following way (excuse Gmail please):
PDEO is removed from lists
->pde_users is 0
PDE won't be in purge queue -- no ->release while module is alive
Current code removes PDEO
On Tue, Aug 28, 2012 at 09:11:57PM -0700, Eric Dumazet wrote:
> On Tue, 2012-08-28 at 23:38 +0300, Alexey Dobriyan wrote:
>
> > Nothing can stop RCU!
> >
> > After running "modprobe;rmmod" in a loop and "cat" in another loop for a
> > while
> > rmmod got stuck in D-state inside remove_proc_entry
On Tue, 2012-08-28 at 23:38 +0300, Alexey Dobriyan wrote:
> Nothing can stop RCU!
>
> After running "modprobe;rmmod" in a loop and "cat" in another loop for a while
> rmmod got stuck in D-state inside remove_proc_entry() with trace amounts of
> CPU time
> being consumed.
>
> It didn't oopsed, t
On Wed, Aug 22, 2012 at 11:42:58PM +0200, Eric Dumazet wrote:
> On Wed, 2012-08-22 at 20:28 +0200, Eric Dumazet wrote:
>
> >
> > Thats interesting, but if you really want this to fly, one RCU
> > conversion would be much better ;)
> >
> > pde_users would be an atomic_t and you would avoid the sp
On Fri, Aug 24, 2012 at 11:45:45AM -0500, Nathan Zimmer wrote:
> On 08/24/2012 09:58 AM, Eric Dumazet wrote:
>> Le vendredi 24 août 2012 à 09:48 -0500, Nathan Zimmer a écrit :
>>> On Wed, Aug 22, 2012 at 11:42:58PM +0200, Eric Dumazet wrote:
On Wed, 2012-08-22 at 20:28 +0200, Eric Dumazet wrot
On 08/24/2012 09:58 AM, Eric Dumazet wrote:
Le vendredi 24 août 2012 à 09:48 -0500, Nathan Zimmer a écrit :
On Wed, Aug 22, 2012 at 11:42:58PM +0200, Eric Dumazet wrote:
On Wed, 2012-08-22 at 20:28 +0200, Eric Dumazet wrote:
Thats interesting, but if you really want this to fly, one RCU
conve
Le vendredi 24 août 2012 à 09:48 -0500, Nathan Zimmer a écrit :
> On Wed, Aug 22, 2012 at 11:42:58PM +0200, Eric Dumazet wrote:
> > On Wed, 2012-08-22 at 20:28 +0200, Eric Dumazet wrote:
> >
> > >
> > > Thats interesting, but if you really want this to fly, one RCU
> > > conversion would be much
On Wed, Aug 22, 2012 at 11:42:58PM +0200, Eric Dumazet wrote:
> On Wed, 2012-08-22 at 20:28 +0200, Eric Dumazet wrote:
>
> >
> > Thats interesting, but if you really want this to fly, one RCU
> > conversion would be much better ;)
> >
> > pde_users would be an atomic_t and you would avoid the sp
On 08/22/2012 04:42 PM, Eric Dumazet wrote:
On Wed, 2012-08-22 at 20:28 +0200, Eric Dumazet wrote:
Thats interesting, but if you really want this to fly, one RCU
conversion would be much better ;)
pde_users would be an atomic_t and you would avoid the spinlock
contention.
Here is what I had i
On Wed, 2012-08-22 at 20:28 +0200, Eric Dumazet wrote:
>
> Thats interesting, but if you really want this to fly, one RCU
> conversion would be much better ;)
>
> pde_users would be an atomic_t and you would avoid the spinlock
> contention.
Here is what I had in mind, I would be interested to k
On Wed, 2012-08-22 at 11:38 -0500, Nathan Zimmer wrote:
> This moves a kfree outside a spinlock to help scaling on larger (512 core)
> systems.
>
> I ran a simple test which just reads from /proc/cpuinfo.
> Lower is better, as you can see the worst case scenario is improved.
>
> baseline
13 matches
Mail list logo
