On Wed, Sep 25, 2013 at 8:00 AM, Greg Stark wrote:
>
> On Wed, Sep 25, 2013 at 12:15 AM, Daniel Farina wrote:
>>
>> Enable the memcg OOM killer only for user faults, where it's really the
>> only option available.
>
>
> Is this really a big deal? I would expect most faults to be user faults.
>
>
On Wed, Sep 25, 2013 at 12:15 AM, Daniel Farina wrote:
> Enable the memcg OOM killer only for user faults, where it's really the
> only option available.
>
Is this really a big deal? I would expect most faults to be user faults.
It's certainly a big deal that we need to ensure we can handle ENO
On Sep 24, 2013 10:12 AM, "Josh Berkus" wrote:
>
> All,
>
> I've send kernel.org a message that we're keen on seeing these changes
> become committed.
I thought it was merged already in 3.12. There are a few related
patches, but here's one:
commit 519e52473ebe9db5cdef44670d5a97f1fd53d721
Author:
All,
I've send kernel.org a message that we're keen on seeing these changes
get committed.
BTW, in the future if anyone sees kernel.org contemplating a patch which
helps or hurts Postgres, don't hesiate to speak up to them. They don't
get nearly enough feedback from DB developers.
--
Josh Berk
All,
I've send kernel.org a message that we're keen on seeing these changes
become committed.
BTW, in the future if anyone sees kernel.org contemplating a patch which
helps or hurts Postgres, don't hesiate to speak up to them. They don't
get nearly enough feedback from DB developers.
--
Josh B
Robert Haas writes:
> I laughed, too, but the reality is that at least as far as PG is
> concerned it's probably a truthful statement, and if it isn't, nobody
> here is likely to complain about having to fix it. Yeah, there's a
> lot of other code out there not as well written or maintained as PG
Andres Freund writes:
> What has changed is how to react to situations where memory has been
> overcommitted but is now actually needed.
Sure. You either have a failure at malloc() or usage, over commit is all
about never failing at malloc(), but now you have to deal with OOM
conditions in creati
On 2013-09-19 11:49:05 -0400, Robert Haas wrote:
> On Thu, Sep 19, 2013 at 11:30 AM, Merlin Moncure wrote:
> > On Thu, Sep 19, 2013 at 9:12 AM, Robert Haas wrote:
> >>> But, naturally, that will not be a problem
> >>> since all user-space code diligently checks the return status of every
> >>> sy
On Thu, Sep 19, 2013 at 12:02 PM, Andres Freund wrote:
> The "problem" is that it's not just about malloc() (aka brk() and
> mmap()) and friends. It's about many of the other systemcalls. Like
> e.g. send() to name one of the more likely ones.
*shrug*
If you're using for send() and not testing f
On 2013-09-19 18:23:07 +0200, Dimitri Fontaine wrote:
> I've been told at several instances that this has been made for the JVM
> and other such programs that want to allocate huge amount of memory even
> if they don't really intend to use it.
That's not really related - what you describe is memor
On Thu, Sep 19, 2013 at 11:30 AM, Merlin Moncure wrote:
> On Thu, Sep 19, 2013 at 9:12 AM, Robert Haas wrote:
>>> But, naturally, that will not be a problem
>>> since all user-space code diligently checks the return status of every
>>> system call and responds with well-tested error-handling code
On Thu, Sep 19, 2013 at 9:12 AM, Robert Haas wrote:
>> But, naturally, that will not be a problem
>> since all user-space code diligently checks the return status of every
>> system call and responds with well-tested error-handling code when
>> things go wrong.
That just short circuited my sarcas
On Wed, Sep 18, 2013 at 10:09 PM, Daniel Farina wrote:
> I'm not sure how many of you have been tracking this but courtesy of
> lwn.net I have learned that it seems that the OOM killer behavior in
> Linux 3.12 will be significantly different. And by description, it
> sounds like an improvement.
I'm not sure how many of you have been tracking this but courtesy of
lwn.net I have learned that it seems that the OOM killer behavior in
Linux 3.12 will be significantly different. And by description, it
sounds like an improvement. I thought some people reading -hackers
might be interested.
Bas
14 matches
Mail list logo
