remove _STK_LIM_MAX override

remove _STK_LIM_MAX override

[Helge Deller]

Dear metag people,

on the parisc arch we found a problem with GNU make, that our process stacks became too big so that many debian packages didn't built because not enough threads (started via GNU make) could be created. 

The final solution was to remove our arch-specifc _STK_LIM_MAX override.
I will push this patch for parisc upstream soon:
https://patchwork.kernel.org/patch/4072991/

It seems metag is now the only arch left which overrides _STK_LIM_MAX.
Maybe you need to revisit that too?

Helge
--
To unsubscribe from this list: send the line "unsubscribe linux-metag" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: remove _STK_LIM_MAX override

[James Hogan]

On 28 April 2014 20:21, Helge Deller <deller-Mmb7MZpHnFY@public.gmane.org> wrote:
> Dear metag people,
>
> on the parisc arch we found a problem with GNU make, that our process stacks became too big so that many debian packages didn't built because not enough threads (started via GNU make) could be created.
>
> The final solution was to remove our arch-specifc _STK_LIM_MAX override.
> I will push this patch for parisc upstream soon:
> https://patchwork.kernel.org/patch/4072991/
>
> It seems metag is now the only arch left which overrides _STK_LIM_MAX.
> Maybe you need to revisit that too?

Thanks Helge, I'll look into that.

Presumably the parisc resource.h can be removed and added to generic-y
now if _STK_LIM_MAX is removed?

Cheers
James
--
To unsubscribe from this list: send the line "unsubscribe linux-metag" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: remove _STK_LIM_MAX override

[Helge Deller]

On 04/29/2014 01:11 AM, James Hogan wrote:
> On 28 April 2014 20:21, Helge Deller <deller-Mmb7MZpHnFY@public.gmane.org> wrote:
>> Dear metag people,
>>
>> on the parisc arch we found a problem with GNU make, that our process stacks became too big so that many debian packages didn't built because not enough threads (started via GNU make) could be created.
>>
>> The final solution was to remove our arch-specifc _STK_LIM_MAX override.
>> I will push this patch for parisc upstream soon:
>> https://patchwork.kernel.org/patch/4072991/
>>
>> It seems metag is now the only arch left which overrides _STK_LIM_MAX.
>> Maybe you need to revisit that too?
> 
> Thanks Helge, I'll look into that.
> 
> Presumably the parisc resource.h can be removed and added to generic-y
> now if _STK_LIM_MAX is removed?

Yes, I will change that too.

Helge
--
To unsubscribe from this list: send the line "unsubscribe linux-metag" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: remove _STK_LIM_MAX override

[James Hogan]

[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]

On 28/04/14 20:21, Helge Deller wrote:
> Dear metag people,
> 
> on the parisc arch we found a problem with GNU make, that our process stacks became too big so that many debian packages didn't built because not enough threads (started via GNU make) could be created. 
> 
> The final solution was to remove our arch-specifc _STK_LIM_MAX override.
> I will push this patch for parisc upstream soon:
> https://patchwork.kernel.org/patch/4072991/
> 
> It seems metag is now the only arch left which overrides _STK_LIM_MAX.
> Maybe you need to revisit that too?

Hi Helge,

Could you clarify the exact problem? As far as I can tell from strace
experimentation GNU make will reset the RLIMIT_STACK soft limit to it's
previous value prior to forking off any children, and doesn't appear to
make use of pthreads itself either.

That's not to say the default hard limit override shouldn't be removed.
I think it was only there to prevent the excessively large 1GB default
stack size being used and causing problems with Meta's limited virtual
address space (which is effectively fixed by your other patch).

Thanks
James


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]