Bug 175100

Created attachment 317035 [details] Patch

Comment on attachment 317035 [details] Patch r=me. Please add your rationale for why this change is needed in the ChangeLog. Thanks.

I don’t think this is the right fix. Can you instead run under ulimit ?

Comment on attachment 317035 [details] Patch r=me too. I know that you elaborated in the bugzilla comment, but it would be even nicer if the ChangeLog also contained the text about why this test doesn't make sense on Linux.

(In reply to JF Bastien from comment #3) > I don’t think this is the right fix. Can you instead run under ulimit ? I think it's more pragmatic to just do this fix. We're always open to ports skipping tests without much fuss. In particular, I would have even been OK with Carlos landing this change without review, since test gardening technically does not need review.

(In reply to JF Bastien from comment #3) > I don’t think this is the right fix. Can you instead run under ulimit ? ulimit is pretty broken on Linux, as limiting by rss (ulimit -m) doesn't work at all on Linux (since kernels 2.4.x) and limiting by vsize (ulimit -v ) requires some hard-to-get-right ad-hoc knowledge about how much virtual size is acceptable for a process to allocate. For example, this test is allocating ~15GB of RSS and ~57GB of VSZ before giving the out of memory error on a Linux machine with 16GB of RAM. So, how should I know that I should set an ulimit on 57GB other than by try and error? Playing with limiting the vsize seems a bit fragile to me. The only thing that I know works ok on Linux for limiting memory usage are cgroups. But cgroups are meant to limit the memory usage of a group of process (its usually used with containers). They are not really meant to limit the memory usage of a single process like we would like to do in this case. There is also the issue that this problem will not only trigger on the bots, but also on the developers machines. Any WebKit Linux developer trying to run this test will likely run into desktop freezes. I'm seizing this to comment also about a related issue at https://bugs.webkit.org/show_bug.cgi?id=171630#c11 where I observed that WebKit/JSC is pretty unique in the sense that we allow a script to use all possible RAM of the system. Other JS engines seem to limit this value to some sane amount (like 4 GBs). I see how on MacOS allow this is not a problem as the Mac kernel seems to handle fine this situations, but on Linux we run into problems when this happens.

Committed r220173: <http://trac.webkit.org/changeset/220173>

<rdar://problem/33691382>

(In reply to Carlos Alberto Lopez Perez from comment #6) > (In reply to JF Bastien from comment #3) > > I don’t think this is the right fix. Can you instead run under ulimit ? > > ulimit is pretty broken on Linux, as limiting by rss (ulimit -m) doesn't > work at all on Linux (since kernels 2.4.x) and limiting by vsize (ulimit -v > ) requires some hard-to-get-right ad-hoc knowledge about how much virtual > size is acceptable for a process to allocate. > > For example, this test is allocating ~15GB of RSS and ~57GB of VSZ before > giving the out of memory error on a Linux machine with 16GB of RAM. So, how > should I know that I should set an ulimit on 57GB other than by try and > error? Playing with limiting the vsize seems a bit fragile to me. The test just tries to run out. Doesn’t matter at how much memory. > The only thing that I know works ok on Linux for limiting memory usage are > cgroups. But cgroups are meant to limit the memory usage of a group of > process (its usually used with containers). They are not really meant to > limit the memory usage of a single process like we would like to do in this > case. > > There is also the issue that this problem will not only trigger on the bots, > but also on the developers machines. Any WebKit Linux developer trying to > run this test will likely run into desktop freezes. > > > I'm seizing this to comment also about a related issue at > https://bugs.webkit.org/show_bug.cgi?id=171630#c11 where I observed that > WebKit/JSC is pretty unique in the sense that we allow a script to use all > possible RAM of the system. Other JS engines seem to limit this value to > some sane amount (like 4 GBs). I see how on MacOS allow this is not a > problem as the Mac kernel seems to handle fine this situations, but on Linux > we run into problems when this happens.