Re: [webkit-dev] Tools/Scripts/build-webkit --gtk --debug --makeargs=-j1 taking up to 80% of memory
On Mon, 2011-12-26 at 21:45 -0800, sachin nikam wrote: I synced up the latest webkit code base and am trying to build webkit gtk on ubuntu 11.10 with 4gb of RAM and 4 CPUs I tried with --makeargs=-j2 but still got ld process terminated signal[9] error ?which indicates that it ran out of memory. I suspect i will still the get the same error with --makeargs=-j1. Is there any other flag where we can restrict the memory usage? Regards Sachin I had the same problem after I've upgraded my PC to 12 GB of RAM. Before upgrade I was able to build 32 bit webkit on my 4 GB computer with Ubuntu 11.10 32-bit with PAE and 8 GB of swap. So what I recommend is to remove 1 GB of memory (or load something heavy to take that 1GB of RAM) and add more swap. Physical address extension doesn't allow any process to take more than [specific amount] of physical RAM, so swap must be used. In your case it seems like swap is never used, so the system fails to address additional physical memory you have. But I highly recommend upgrading your computer to minimum of 8 GB of RAM and install 64 bit Ubuntu. If you really need 32-bit build, cross-compiling might be an option. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] chromium-cg-mac results
I agree that it is reasonable (and a good idea) to remove the chromium-cg-mac expectations from WebKit now, and I am willing to take the lead on doing so (although I will need help from WebKit committers). Please let me know if anyone agrees/disagrees with the following steps to do so: 1. remove the following buildbots that rely on chromium-cg-mac expectations (otherwise, they will start failing once the CG expectations disappear): - http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac%20Builder%20%28CG%29%28deps%29 - http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20%28CG%29%28deps%29 - http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac%20Builder%20%28CG%29 - http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.5%20%28CG%29 - http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20%28CG%29 - http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac%20Builder%20%28CG%29%28dbg%29 - http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.5%20%28CG%29%28dbg%29%281%29 - http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.5%20%28CG%29%28dbg%29%282%29 - http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20%28CG%29%28dbg%29 2. remove the LayoutTests/platform/*-cg-* directories from the WebKit repo 3. remove any CG-specific entries from LayoutTests/platform/chromium/test-expectations.txt 4. remove any CG-specific test code from the Tools/Scripts/webkitpy tree On Wed, Jan 4, 2012 at 12:01 AM, David Levin le...@chromium.org wrote: On Tue, Jan 3, 2012 at 8:33 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Jan 3, 2012 at 3:28 PM, Adam Barth aba...@webkit.org wrote: On Tue, Jan 3, 2012 at 3:22 PM, Nico Weber tha...@chromium.org wrote: On Tue, Jan 3, 2012 at 3:00 PM, Adam Barth aba...@webkit.org wrote: It looks like Chromium Mac has successfully moved to Skia. I'd wait with this assessment until a version of Chrome with Skia has shipped to stable. Things are looking really good so that should be smooth sailing, but it's a bit early to say we're successfully moved :-) Fair enough. However, I believe the Skia transition plan called for removing the chromium-cg-mac expectation much earlier than a Skia build shipping to stable. Originally, we were only supposed to have to maintain both sets of expectations for about a month. The transition has taken longer than expected, but it seems like we have sufficient confidence in Skia now that we can remove the chromium-cg-mac expectations. Has the skia transition hit beta yet? It seems like as soon as we get it onto a version that is pointing to a branched version of webkit, we should be completely safe to remove the directories on trunk (frankly, I'd agree with Adam that it's probably safe to remove it now, since we can always add them back in if we have to, but I can compromise as well). Remove it. It is a cost on everyone who enlists in WebKit. Those of us who aren't creating new enlistments are not affected much but that doesn't mean it isn't costly. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] chromium-cg-mac results
5. Moving forward, reviewers and committers take care not to re-add expectations when committing pending patches. While I expect svn will warn in most cases, I doubt that it will catch everything. 6. Won't fix any bugs related to chromium-cg results. Stephen. On Wed, Jan 4, 2012 at 9:10 AM, Elliot Poger epo...@chromium.org wrote: I agree that it is reasonable (and a good idea) to remove the chromium-cg-mac expectations from WebKit now, and I am willing to take the lead on doing so (although I will need help from WebKit committers). Please let me know if anyone agrees/disagrees with the following steps to do so: 1. remove the following buildbots that rely on chromium-cg-mac expectations (otherwise, they will start failing once the CG expectations disappear): - http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac%20Builder%20%28CG%29%28deps%29 - http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20%28CG%29%28deps%29 - http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac%20Builder%20%28CG%29 - http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.5%20%28CG%29 - http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20%28CG%29 - http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac%20Builder%20%28CG%29%28dbg%29 - http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.5%20%28CG%29%28dbg%29%281%29 - http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.5%20%28CG%29%28dbg%29%282%29 - http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20%28CG%29%28dbg%29 2. remove the LayoutTests/platform/*-cg-* directories from the WebKit repo 3. remove any CG-specific entries from LayoutTests/platform/chromium/test-expectations.txt 4. remove any CG-specific test code from the Tools/Scripts/webkitpy tree On Wed, Jan 4, 2012 at 12:01 AM, David Levin le...@chromium.org wrote: On Tue, Jan 3, 2012 at 8:33 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Jan 3, 2012 at 3:28 PM, Adam Barth aba...@webkit.org wrote: On Tue, Jan 3, 2012 at 3:22 PM, Nico Weber tha...@chromium.org wrote: On Tue, Jan 3, 2012 at 3:00 PM, Adam Barth aba...@webkit.org wrote: It looks like Chromium Mac has successfully moved to Skia. I'd wait with this assessment until a version of Chrome with Skia has shipped to stable. Things are looking really good so that should be smooth sailing, but it's a bit early to say we're successfully moved :-) Fair enough. However, I believe the Skia transition plan called for removing the chromium-cg-mac expectation much earlier than a Skia build shipping to stable. Originally, we were only supposed to have to maintain both sets of expectations for about a month. The transition has taken longer than expected, but it seems like we have sufficient confidence in Skia now that we can remove the chromium-cg-mac expectations. Has the skia transition hit beta yet? It seems like as soon as we get it onto a version that is pointing to a branched version of webkit, we should be completely safe to remove the directories on trunk (frankly, I'd agree with Adam that it's probably safe to remove it now, since we can always add them back in if we have to, but I can compromise as well). Remove it. It is a cost on everyone who enlists in WebKit. Those of us who aren't creating new enlistments are not affected much but that doesn't mean it isn't costly. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] chromium-cg-mac results
On Wed, Jan 4, 2012 at 6:10 AM, Elliot Poger epo...@chromium.org wrote: I agree that it is reasonable (and a good idea) to remove the chromium-cg-mac expectations from WebKit now, and I am willing to take the lead on doing so (although I will need help from WebKit committers). Sounds like a good plan. I'm happy to help. Let's coordinate off-list. Thanks, Adam Please let me know if anyone agrees/disagrees with the following steps to do so: 1. remove the following buildbots that rely on chromium-cg-mac expectations (otherwise, they will start failing once the CG expectations disappear): http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac%20Builder%20%28CG%29%28deps%29 http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20%28CG%29%28deps%29 http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac%20Builder%20%28CG%29 http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.5%20%28CG%29 http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20%28CG%29 http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac%20Builder%20%28CG%29%28dbg%29 http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.5%20%28CG%29%28dbg%29%281%29 http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.5%20%28CG%29%28dbg%29%282%29 http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20%28CG%29%28dbg%29 2. remove the LayoutTests/platform/*-cg-* directories from the WebKit repo 3. remove any CG-specific entries from LayoutTests/platform/chromium/test-expectations.txt 4. remove any CG-specific test code from the Tools/Scripts/webkitpy tree On Wed, Jan 4, 2012 at 12:01 AM, David Levin le...@chromium.org wrote: On Tue, Jan 3, 2012 at 8:33 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Jan 3, 2012 at 3:28 PM, Adam Barth aba...@webkit.org wrote: On Tue, Jan 3, 2012 at 3:22 PM, Nico Weber tha...@chromium.org wrote: On Tue, Jan 3, 2012 at 3:00 PM, Adam Barth aba...@webkit.org wrote: It looks like Chromium Mac has successfully moved to Skia. I'd wait with this assessment until a version of Chrome with Skia has shipped to stable. Things are looking really good so that should be smooth sailing, but it's a bit early to say we're successfully moved :-) Fair enough. However, I believe the Skia transition plan called for removing the chromium-cg-mac expectation much earlier than a Skia build shipping to stable. Originally, we were only supposed to have to maintain both sets of expectations for about a month. The transition has taken longer than expected, but it seems like we have sufficient confidence in Skia now that we can remove the chromium-cg-mac expectations. Has the skia transition hit beta yet? It seems like as soon as we get it onto a version that is pointing to a branched version of webkit, we should be completely safe to remove the directories on trunk (frankly, I'd agree with Adam that it's probably safe to remove it now, since we can always add them back in if we have to, but I can compromise as well). Remove it. It is a cost on everyone who enlists in WebKit. Those of us who aren't creating new enlistments are not affected much but that doesn't mean it isn't costly. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] chromium-cg-mac results
Filed https://bugs.webkit.org/show_bug.cgi?id=75548 ('[rollup] remove
chromium-cg-mac baselines')
On Wed, Jan 4, 2012 at 10:37 AM, Adam Barth aba...@webkit.org wrote:
On Wed, Jan 4, 2012 at 6:10 AM, Elliot Poger epo...@chromium.org wrote:
I agree that it is reasonable (and a good idea) to remove the
chromium-cg-mac expectations from WebKit now, and I am willing to take
the
lead on doing so (although I will need help from WebKit committers).
Sounds like a good plan. I'm happy to help. Let's coordinate off-list.
Thanks,
Adam
Please let me know if anyone agrees/disagrees with the following steps
to do
so:
1. remove the following buildbots that rely on chromium-cg-mac
expectations
(otherwise, they will start failing once the CG expectations disappear):
http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac%20Builder%20%28CG%29%28deps%29
http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20%28CG%29%28deps%29
http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac%20Builder%20%28CG%29
http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.5%20%28CG%29
http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20%28CG%29
http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac%20Builder%20%28CG%29%28dbg%29
http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.5%20%28CG%29%28dbg%29%281%29
http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.5%20%28CG%29%28dbg%29%282%29
http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20%28CG%29%28dbg%29
2. remove the LayoutTests/platform/*-cg-* directories from the WebKit
repo
3. remove any CG-specific entries from
LayoutTests/platform/chromium/test-expectations.txt
4. remove any CG-specific test code from the Tools/Scripts/webkitpy tree
On Wed, Jan 4, 2012 at 12:01 AM, David Levin le...@chromium.org wrote:
On Tue, Jan 3, 2012 at 8:33 PM, Dirk Pranke dpra...@chromium.org
wrote:
On Tue, Jan 3, 2012 at 3:28 PM, Adam Barth aba...@webkit.org wrote:
On Tue, Jan 3, 2012 at 3:22 PM, Nico Weber tha...@chromium.org
wrote:
On Tue, Jan 3, 2012 at 3:00 PM, Adam Barth aba...@webkit.org
wrote:
It looks like Chromium Mac has successfully moved to Skia.
I'd wait with this assessment until a version of Chrome with Skia
has
shipped to stable. Things are looking really good so that should be
smooth sailing, but it's a bit early to say we're successfully
moved
:-)
Fair enough. However, I believe the Skia transition plan called for
removing the chromium-cg-mac expectation much earlier than a Skia
build shipping to stable. Originally, we were only supposed to have
to maintain both sets of expectations for about a month. The
transition has taken longer than expected, but it seems like we have
sufficient confidence in Skia now that we can remove the
chromium-cg-mac expectations.
Has the skia transition hit beta yet? It seems like as soon as we get
it onto a version that is pointing to a branched version of webkit, we
should be completely safe to remove the directories on trunk (frankly,
I'd agree with Adam that it's probably safe to remove it now, since we
can always add them back in if we have to, but I can compromise as
well).
Remove it.
It is a cost on everyone who enlists in WebKit. Those of us who aren't
creating new enlistments are not affected much but that doesn't mean it
isn't costly.
dave
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making overflow clipping cheaper
I'd be careful in how I approach this. Some platforms are going to want compositing of overflow sections eventually for fast scrolling of those sections. RenderLayer has become the natural tie-in point for GraphicsLayer connections. This is something I don't want to prevent. That said it looks like my proposal (and current view on RenderLayer) is going against the current situation where RenderLayer is the only tie-in for GraphicsLayer. I don't know if splitting part of RenderLayer is totally against the goal of having that part composited. This just means that we need to change our paradigm and enable more classes to be composited. Note that the proposal is rough as there are different functionalities handled by RenderLayer (repainting, hit testing, ...) that would need to be properly patched for the new code path. In the future I envision overflow sections being more justified in having layers by virtue of the fact that they would always be composited. Hardware acceleration will definitely make us faster on some operations. I am concerned by the fact that this does not solve our core issue - namely RenderLayer is too generic for most cases and ends up hurting performance. As pages become more complex, those pain points will show up more and more (hit testing AFAICT is still done in software thus will not gain from accelerated composition). Thanks, Julien ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making overflow clipping cheaper
On Jan 4, 2012, at 2:36 PM, Julien Chaffraix wrote: namely RenderLayer is too generic for most cases and ends up hurting performance. In what way? Overflow clips create layers, but they do not paint or hit test at the layer level unless they are self-painting layers. They only become self-painting layers if some other property is present that causes this to happen, e.g., absolute positioning. Perhaps you could point me to the specific performance problems that you're seeing that are caused by overflow and layers, since we already should be avoiding the self-painting layer code paths for overflow that doesn't need a layer for some other reason. Note I have no real objection RenderLayers using mix-ins or composition to bring in scrolling functionality. That seems sensible if that's all you're planning. I'd just like to understand the performance concerns more, since it's not clear to me what your specific performance issues are. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] layout tests: how are some compared against image, and others only text?
What is it that causes some tests to require baseline images (and not text files) for comparison, while others require text and not image baselines? (I know that I can specifically SKIP comparison against IMAGE and/or TEXT using test_expectations.txt... but even without the use of test_expectations, I believe that some tests are compared against only text or only image.) As an example, I see that this test has only image baselines and no text baselines: $ ls LayoutTests/platform/*/fast/canvas/canvas-text-baseline*.png | wc -l 10 $ ls LayoutTests/platform/*/fast/canvas/canvas-text-baseline*.txt | wc -l ls: cannot access LayoutTests/platform/*/fast/canvas/canvas-text-baseline*.txt: No such file or directory 0 while this test has only text baselines and no image baselines: $ ls LayoutTests/platform/*/fast/canvas/canvas-lineWidth*.png | wc -l ls: cannot access LayoutTests/platform/*/fast/canvas/canvas-lineWidth*.png: No such file or directory 0 $ ls LayoutTests/platform/*/fast/canvas/canvas-lineWidth*.txt | wc -l 5 Is there something inherent in each test that indicates whether its results will be compared against image and/or text baselines? Or is it simply a matter of what baseline files are found to compare against? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] layout tests: how are some compared against image, and others only text?
This is probably more appropriate for webkit-help but... In general, tests that call layoutTestController.dumpAsTest() or layoutTestController.dumpAsTest(false) and ref tests don't have expected.png files. I'm not aware of tests that don't require expected.txt however. Maybe they're specific to some canvas tests? - Ryosuke On Wed, Jan 4, 2012 at 3:39 PM, Elliot Poger epo...@chromium.org wrote: What is it that causes some tests to require baseline images (and not text files) for comparison, while others require text and not image baselines? (I know that I can specifically SKIP comparison against IMAGE and/or TEXT using test_expectations.txt... but even without the use of test_expectations, I believe that some tests are compared against only text or only image.) As an example, I see that this test has only image baselines and no text baselines: $ ls LayoutTests/platform/*/fast/canvas/canvas-text-baseline*.png | wc -l 10 $ ls LayoutTests/platform/*/fast/canvas/canvas-text-baseline*.txt | wc -l ls: cannot access LayoutTests/platform/*/fast/canvas/canvas-text-baseline*.txt: No such file or directory 0 while this test has only text baselines and no image baselines: $ ls LayoutTests/platform/*/fast/canvas/canvas-lineWidth*.png | wc -l ls: cannot access LayoutTests/platform/*/fast/canvas/canvas-lineWidth*.png: No such file or directory 0 $ ls LayoutTests/platform/*/fast/canvas/canvas-lineWidth*.txt | wc -l 5 Is there something inherent in each test that indicates whether its results will be compared against image and/or text baselines? Or is it simply a matter of what baseline files are found to compare against? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] layout tests: how are some compared against image, and others only text?
On Wed, Jan 4, 2012 at 3:39 PM, Elliot Poger epo...@chromium.org wrote: What is it that causes some tests to require baseline images (and not text files) for comparison, while others require text and not image baselines? (I know that I can specifically SKIP comparison against IMAGE and/or TEXT using test_expectations.txt... but even without the use of test_expectations, I believe that some tests are compared against only text or only image.) As an example, I see that this test has only image baselines and no text baselines: $ ls LayoutTests/platform/*/fast/canvas/canvas-text-baseline*.png | wc -l 10 $ ls LayoutTests/platform/*/fast/canvas/canvas-text-baseline*.txt | wc -l ls: cannot access LayoutTests/platform/*/fast/canvas/canvas-text-baseline*.txt: No such file or directory 0 Wrong, you've missed some: $ find LayoutTests/ -name canvas-text-baseline* LayoutTests/platform/chromium-linux/fast/canvas/canvas-text-baseline-expected.png LayoutTests/platform/gtk/fast/canvas/canvas-text-baseline-expected.png LayoutTests/platform/qt/fast/canvas/canvas-text-baseline-expected.png LayoutTests/platform/efl/fast/canvas/canvas-text-baseline-expected.png LayoutTests/platform/chromium-win/fast/canvas/canvas-text-baseline-expected.png LayoutTests/platform/chromium-gpu-linux/fast/canvas/canvas-text-baseline-expected.png LayoutTests/platform/chromium-gpu-win/fast/canvas/canvas-text-baseline-expected.png LayoutTests/platform/mac/fast/canvas/canvas-text-baseline-expected.png LayoutTests/fast/canvas/canvas-text-baseline.html LayoutTests/fast/canvas/canvas-text-baseline-expected.txt this one applies while this test has only text baselines and no image baselines: $ ls LayoutTests/platform/*/fast/canvas/canvas-lineWidth*.png | wc -l ls: cannot access LayoutTests/platform/*/fast/canvas/canvas-lineWidth*.png: No such file or directory 0 $ ls LayoutTests/platform/*/fast/canvas/canvas-lineWidth*.txt | wc -l 5 This test calls layoutTestController.dumpAsText() (in js-test-pre.js), so there's no .png. - James Is there something inherent in each test that indicates whether its results will be compared against image and/or text baselines? Or is it simply a matter of what baseline files are found to compare against? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tools/Scripts/build-webkit --gtk --debug --makeargs=-j1 taking up to 80% of memory
i am running ubuntu 11.10 64 bit. I was able to eventually build with --makeargs=-j1. I will try increase the swap space and see if it helps. Regards Sachin On Wed, Jan 4, 2012 at 3:55 AM, John Yani van...@gmail.com wrote: On Mon, 2011-12-26 at 21:45 -0800, sachin nikam wrote: I synced up the latest webkit code base and am trying to build webkit gtk on ubuntu 11.10 with 4gb of RAM and 4 CPUs I tried with --makeargs=-j2 but still got ld process terminated signal[9] error ?which indicates that it ran out of memory. I suspect i will still the get the same error with --makeargs=-j1. Is there any other flag where we can restrict the memory usage? Regards Sachin I had the same problem after I've upgraded my PC to 12 GB of RAM. Before upgrade I was able to build 32 bit webkit on my 4 GB computer with Ubuntu 11.10 32-bit with PAE and 8 GB of swap. So what I recommend is to remove 1 GB of memory (or load something heavy to take that 1GB of RAM) and add more swap. Physical address extension doesn't allow any process to take more than [specific amount] of physical RAM, so swap must be used. In your case it seems like swap is never used, so the system fails to address additional physical memory you have. But I highly recommend upgrading your computer to minimum of 8 GB of RAM and install 64 bit Ubuntu. If you really need 32-bit build, cross-compiling might be an option. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Asking for review by pinging bugs---another approach
Not to pick on anyone in particular, but when reading bugmail I occasionally see messages like pinging for review. I review a lot of patches, but I don't find these messages particularly helpful because I don't know whether I'm supposed to review the patch. Another approach that might work better for you is to address your comment at someone in particular. For example, if the message says Adam, can you please review this patch?, then there's a pretty good chance I'll click through and try to answer your question. If you're unsure who to ask for review, one approach is to look at the svn log for the files you're changing and see who has written/reviewed patches for those files recently. You can also ask folks who've been around the project for a while to suggest someone. Good luck, and happy hacking, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
