Sent by Bird Mail___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
Thanks agentzh, Maxim and Igor
On Tue, Jun 3, 2014 at 11:00 AM, Maxim Dounin wrote:
> Hello!
>
> On Mon, Jun 02, 2014 at 08:42:50PM +0400, Maxim Dounin wrote:
>
> > Hello!
> >
> > On Sat, May 31, 2014 at 11:46:28PM -0300, Wandenberg Peixoto wrote:
> >
> > > Hello Maxim,
> > >
> > > I executed m
Hello!
On Mon, Jun 02, 2014 at 08:42:50PM +0400, Maxim Dounin wrote:
> Hello!
>
> On Sat, May 31, 2014 at 11:46:28PM -0300, Wandenberg Peixoto wrote:
>
> > Hello Maxim,
> >
> > I executed my tests again and seems that your improved patch version is
> > working fine too.
>
> Good, thanks for t
Hello!
On Sat, May 31, 2014 at 11:46:28PM -0300, Wandenberg Peixoto wrote:
> Hello Maxim,
>
> I executed my tests again and seems that your improved patch version is
> working fine too.
Good, thanks for testing.
> Did you plan to merge it on nginx core soon?
It's currently waiting for Igor's
Hi Maxim!
On Wed, May 28, 2014 at 11:38 AM, Maxim Dounin wrote:
>
> Below is a patch which does mostly the same without introducing
> any additional per-page fields. Please take a look if it works
> for you.
>
Thank you for looking into this!
I've run my local test suite for this issue against
Hello Maxim,
I executed my tests again and seems that your improved patch version is
working fine too.
Did you plan to merge it on nginx core soon?
-agentzh
Did you have opportunity to check if it works for you?
Regards
On Wed, May 28, 2014 at 3:38 PM, Maxim Dounin wrote:
> Hello!
>
> On
Hello Maxim,
I executed my tests again and seems that your improved patch version is
working fine too.
Did you plan to merge it on nginx core soon?
Regards
On Wed, May 28, 2014 at 3:41 PM, Maxim Dounin wrote:
> Hello!
>
> On Wed, Jan 22, 2014 at 08:51:50PM +0400, Maxim Dounin wrote:
>
> > He
Hello!
On Wed, Jan 22, 2014 at 08:51:50PM +0400, Maxim Dounin wrote:
> Hello!
>
> On Wed, Jan 22, 2014 at 01:39:54AM -0200, Wandenberg Peixoto wrote:
>
> > Hello Maxim,
> >
> > did you have opportunity to take a look on this last patch?
>
> It looks more or less correct, though I don't happy
Hello!
On Sun, May 11, 2014 at 10:13:52PM -0700, Yichun Zhang (agentzh) wrote:
> Hello!
>
> On Mon, Jul 29, 2013 at 10:11 AM, Maxim Dounin wrote:
> > Additionally, doing a full merge of all free blocks on a free
> > operation looks too much. It might be something we want to do on
> > allocation
Hello!
On Mon, Jul 29, 2013 at 10:11 AM, Maxim Dounin wrote:
> Additionally, doing a full merge of all free blocks on a free
> operation looks too much. It might be something we want to do on
> allocation failure, but not on a normal path in
> ngx_slab_free_pages(). And/or something lightweight
Hello!
On Fri, Apr 25, 2014 at 12:47:28PM -0700, John Watson wrote:
> Hi Maxim,
>
> Any chance you can fix up this patch and get it into 1.7?
It's still in my queue, I hope I can spend some time on it in the
near future. (It's relatively low priority though, as nothing in
nginx itself uses s
Hello,,
AFAIK, the patch attached here :
http://mailman.nginx.org/pipermail/nginx-devel/2013-December/004721.html
compile, and should work on 1.6 too.
Maybe the merge is a bit tricky with the last changes made on ngx_slab.c
I have a up-to-date version on my patch queue.
as Maxim stated, it stil
Hi Maxim,
Any chance you can fix up this patch and get it into 1.7?
This patch is not compatible with 1.6.
Best,
John
On Wed, Jan 22, 2014 at 8:51 AM, Maxim Dounin wrote:
> Hello!
>
> On Wed, Jan 22, 2014 at 01:39:54AM -0200, Wandenberg Peixoto wrote:
>
>> Hello Maxim,
>>
>> did you have oppo
Hello Maxim!
On Wed, Jan 22, 2014 at 8:51 AM, Maxim Dounin wrote:
>
> It looks more or less correct, though I don't happy with the
> checks done, and there are various style issues. I'm planning to
> look into it and build a better version as time permits.
>
We're also having this issue. Hopeful
Hello!
On Wed, Jan 22, 2014 at 01:39:54AM -0200, Wandenberg Peixoto wrote:
> Hello Maxim,
>
> did you have opportunity to take a look on this last patch?
It looks more or less correct, though I don't happy with the
checks done, and there are various style issues. I'm planning to
look into it
Hello Maxim,
did you have opportunity to take a look on this last patch?
Regards,
Wandenberg
On Thu, Dec 26, 2013 at 10:12 PM, Wandenberg Peixoto
wrote:
> Hello Maxim,
>
> I changed the patch to check only the p->next pointer.
> And checking if the page is in an address less than the (pool->p
Hello Maxim,
I changed the patch to check only the p->next pointer.
And checking if the page is in an address less than the (pool->pages +
pages).
+ngx_slab_page_t *prev, *p;
+ngx_uint_tpages;
+size_tsize;
+
+size = pool->end - (u_char *) pool - sizeof(ngx_slab
Hello!
On Tue, Dec 17, 2013 at 09:05:16PM -0200, Wandenberg Peixoto wrote:
> Hi Maxim,
>
> sorry for the long delay. I hope you remember my issue.
> In attach is the new patch with the changes you suggest.
> Can you check it again? I hope it can be applied to nginx code now.
>
> About this poin
Hi Maxim,
sorry for the long delay. I hope you remember my issue.
In attach is the new patch with the changes you suggest.
Can you check it again? I hope it can be applied to nginx code now.
About this point "2. There is probably no need to check both prev and
next.",
I check both pointers to avo
Hello!
On Wed, Jul 31, 2013 at 12:28:02AM -0300, Wandenberg Peixoto wrote:
> Hello!
>
> Thanks for your help. I hope that the patch be OK now.
> I don't know if the function and variable names are on nginx pattern.
> Feel free to change the patch.
> If you have any other point before accept it,
Hello!
On Mon, Sep 02, 2013 at 11:24:33AM -0300, Wandenberg Peixoto wrote:
> did you have opportunity to take a look on this patch?
Not yet, sorry. It's in my TODO and I'll try to look at it this
week. Overall it seems good enough, but it certainly needs
style/cosmetic cleanup before it can
Hi Maxim,
did you have opportunity to take a look on this patch?
Regards,
Wandenberg
On Wed, Jul 31, 2013 at 12:28 AM, Wandenberg Peixoto
wrote:
> Hello!
>
> Thanks for your help. I hope that the patch be OK now.
> I don't know if the function and variable names are on nginx pattern.
> Feel fr
I've been running a node with this patch on a production machine for 5 days and
am seeing marked improvements. The instance hasn't needed to be restarted
due to "ngx_slab_alloc() failed: no memory". The shared memory usage has been
growing at a far slower rate compared to a node without the patch.
Hello!
Thanks for your help. I hope that the patch be OK now.
I don't know if the function and variable names are on nginx pattern.
Feel free to change the patch.
If you have any other point before accept it, will be a pleasure to fix it.
--- src/core/ngx_slab.c2013-05-06 07:27:10.0 -
Hello!
On Mon, Jul 29, 2013 at 04:01:37PM -0300, Wandenberg Peixoto wrote:
[...]
> What would be an alternative to not loop on pool->pages?
Free memory blocks are linked in pool->free list, it should be
enough to look there.
[...]
--
Maxim Dounin
http://nginx.org/en/donation.html
_
Hello!
I see your point, and I will split the patch to do both actions,
on ngx_slab_free_pages() and on allocation when has a failure.
What would be an alternative to not loop on pool->pages?
Regards,
Wandenberg
On Mon, Jul 29, 2013 at 2:11 PM, Maxim Dounin wrote:
> Hello!
>
> On Sat, Jul 2
Hello!
On Sat, Jul 27, 2013 at 04:10:51PM -0300, Wandenberg Peixoto wrote:
> Hello Maxim.
>
> I've been looking into those functions and guided by your comments
> made the following patch to merge continuous block of memory.
> Can you check if it is ok?
> Comments are welcome.
>
> --- src/core/
Hello Maxim.
I've been looking into those functions and guided by your comments
made the following patch to merge continuous block of memory.
Can you check if it is ok?
Comments are welcome.
--- src/core/ngx_slab.c2013-05-06 07:27:10.0 -0300
+++ src/core/ngx_slab.c2013-07-27 15:54
Hello!
On Fri, Jun 28, 2013 at 10:36:39PM -0300, Wandenberg Peixoto wrote:
> Hi,
>
> I'm trying to understand how the shared memory pool works inside the Nginx.
> To do that, I made a very small module which create a shared memory zone
> with 2097152 bytes,
> and allocating and freeing blocks of
29 matches
Mail list logo
