Markus Gutschke | 1 Jul 01:06 2010

Re: [linux] thin archives and fd limit

On Wed, Jun 30, 2010 at 15:50, Evan Martin <evan <at> chromium.org> wrote:

 - upping the file descriptor ulimit works around it, but you need to
be root to do that

Add this line to your "/etc/security/limits.conf":

  * hard nofile 4096

This will allow users to increase their ulimit settings by calling

  ulimit -n 4096

If that's still too complicated, I think the cost of increasing it for all programs is pretty low. So, we could raise both the hard and the soft limit at the same time. Or we could change our buildscripts to always run:

  ulimit -n `ulimit -H -n`

That would raise the limit just for the buildscript's children.


Markus

--
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Zelidrag Hornung | 1 Jul 01:54 2010

savable schemas

Can someone tell me if there are good reasons why about: is not in the list of savable schemas?

--
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Peter Kasting | 1 Jul 02:37 2010
Picon

Re: savable schemas

On Wed, Jun 30, 2010 at 4:54 PM, Zelidrag Hornung <zelidrag <at> chromium.org> wrote:
Can someone tell me if there are good reasons why about: is not in the list of savable schemas?

What is a savable schema?

Something that can be placed in history?

If so, it's probably to work around the fact that about: URLs (other than about:blank) can't be opened other than at the address bar, so if they appear in History or the New Tab Page they can't be successfully clicked on.  The better solution here is that we rewrite the links to be the chrome:// URLs that underlie those pages, which sidesteps the renderer's restrictions on about:.

PK

--
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Zelidrag Hornung | 1 Jul 03:11 2010

Re: savable schemas


const char* kSavableSchemes[] = {
  kHttpScheme,
  kHttpsScheme,
  kFileScheme,
  kFtpScheme,
  kExtensionScheme,
  NULL
};

about:foo happens to be translated to chrome://about/foo and while some pages under chrome: schema surely should not be savable, I don't see why we would prevent saving any existing about:* into a file.



On Wed, Jun 30, 2010 at 5:37 PM, Peter Kasting <pkasting <at> google.com> wrote:
On Wed, Jun 30, 2010 at 4:54 PM, Zelidrag Hornung <zelidrag <at> chromium.org> wrote:
Can someone tell me if there are good reasons why about: is not in the list of savable schemas?

What is a savable schema?

Something that can be placed in history?

If so, it's probably to work around the fact that about: URLs (other than about:blank) can't be opened other than at the address bar, so if they appear in History or the New Tab Page they can't be successfully clicked on.  The better solution here is that we rewrite the links to be the chrome:// URLs that underlie those pages, which sidesteps the renderer's restrictions on about:.

PK

--
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
tfarina@chromium.org | 1 Jul 04:26 2010

Re: Please don't rubber stamp code reviews

I would like to complement this by asking people to write a good
TEST=description. Many patches are complex, and there is a lack of how
it was tested or is supposed to be tested (in addition to the unittest
per se in the CL). If the author of the patch writes a good test
description is more easy to figure out what he is trying to fix and
how to reproduce the failure he is trying to fix. So my appeal is for,
please everyone try to write good test descriptions to make more easy
for anyone reviewing a patch to understand what is going on.

--

-- 
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe: 
    http://groups.google.com/a/chromium.org/group/chromium-dev

madhav | 1 Jul 05:57 2010
Picon

Build error related to LIBVPX/WEBM on ARM

Hello,
I am trying to build chromium on ARM(latest version: r51337) by
following guide  <at> http://code.google.com/p/chromium/wiki/
LinuxChromiumArm, couldnt build it successfully. The build was OK
before the WebM patch been introduced. so i guess there is some issue
in linking a library. Any idea what could be the problem?

-madhav

Here is the build log:

third_party/ffmpeg/patched-ffmpeg-mt/libavcodec/allcodecs.c: In
function 'avcodec_register_all':
third_party/ffmpeg/patched-ffmpeg-mt/libavcodec/allcodecs.c:359:
error: 'CONFIG_LIBVPX_VP8_ENCODER' undeclared (first use in this
function)
third_party/ffmpeg/patched-ffmpeg-mt/libavcodec/allcodecs.c:359:
error: (Each undeclared identifier is reported only once
third_party/ffmpeg/patched-ffmpeg-mt/libavcodec/allcodecs.c:359:
error: for each function it appears in.)
third_party/ffmpeg/patched-ffmpeg-mt/libavcodec/allcodecs.c:359:
error: 'CONFIG_LIBVPX_VP8_DECODER' undeclared (first use in this
function)
third_party/ffmpeg/patched-ffmpeg-mt/libavformat/allformats.c: In
function 'av_register_all':
third_party/ffmpeg/patched-ffmpeg-mt/libavformat/allformats.c:206:
error: 'CONFIG_WEBM_MUXER' undeclared (first use in this function)
third_party/ffmpeg/patched-ffmpeg-mt/libavformat/allformats.c:206:
error: (Each undeclared identifier is reported only once
third_party/ffmpeg/patched-ffmpeg-mt/libavformat/allformats.c:206:
error: for each function it appears in.)
third_party/ffmpeg/patched-ffmpeg-mt/libavformat/allformats.c:206:
error: 'CONFIG_WEBM_DEMUXER' undeclared (first use in this function)
make: *** [out/Release/obj.target/ffmpegsumo/third_party/ffmpeg/
patched-ffmpeg-mt/libavcodec/allcodecs.o] Error 1
make: *** Waiting for unfinished jobs....
make: *** [out/Release/obj.target/ffmpegsumo/third_party/ffmpeg/
patched-ffmpeg-mt/libavformat/allformats.o] Error 1

--

-- 
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe: 
    http://groups.google.com/a/chromium.org/group/chromium-dev

Amit Joshi | 1 Jul 07:32 2010

Turn on Pre-reading on Windows?

With pre-reading optimization (r50386chrome startup time is under 1000ms on decent machines (down from 3000+ ms). 

Problem: Chrome startup is not bad as a browser but quite slow for chrome frame as a plugin. A big factor in the slowdown is lots and lots of hard page faults during launch. A hard page fault causes disk read as opposed to a 'soft' page fault that simply uses/validates an existing page. 

Solution: 
Pre-read entire chrome.dll before calling LoadLibrary on Windows Vista onwards.

Errr, what? 

Really, buffered read of chrome.dll as a data file in large (1MB) chunks using FILE_FLAG_SEQUENTIAL_SCAN speeds things up spectacularly by bringing in whole of chrome.dll in cache at once. This is much faster than individual page faults. 

Normally during chrome startup, when chrome.dll is loaded and its entry point is called it continuously incurs hard page faults as seen in attached normal.png.  For every page fault the following takes place:
- chrome.exe goes to zzzz.
- memory manager issues page aligned read request for max 32K, or 8 pages (less if next few pages are already in memory).
- the disk will take its own sweet time reading, likely will have to seek first.
- execution resumes and soon another fault happens inside chrome.dll at a random address...

Contrast this to the pre-read scenario:
Allocate 1 MB buffer, continuously read into the same buffer.
- chrome.exe goes to zzzz as before.
- data read requests are issued internally in 64K chunks.
- hints about sequential read speeds up overall reading.
- No page faults in chrome.dll after that!

Please refer to pre_read.png to see how it looks. Note the proportionate timing difference between the two scenarios. The numbers themselves are less indicative as this test was performed on a VM.

This code has been checked in for headless mode and the results are:

Page Cycler Test Results: look for a big drop in startup.

Increase in the IO bytes by ~ 16M on memory test as expected:

Why Vista onwards?
Windows Vista is more aggressive about using available memory for caching. It keeps the chrome.dll pages longer in cache. Vista onwards has superfetch that employs heuristics to monitor startup and speed up things by prefetching/keeping frequently used code/data in memory.
In Windows XP the pre-reading does not work at all since the file cache is quickly discarded and two separate copies are maintained for data vs image cache.

What's the downside?
Pre-reading approach brings in more pages than really necessary. Ideally, chrome.dll should be laid out such that there are different code sections for browser, renderer and so on. Then only those sections need to be warmed up for a particular type of launch. If it's not a lot of pages then we won't need pre-reading at all. Efforts for ordering code used at startup are already underway and should eventually lead us there. 
The worst case behavior is on a system very low in available memory, reading in about 16 MB of data only to be discarded and faulted in subsequently. I suspect that things will be pretty bad already. 

--
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Yuzo Fujishima | 1 Jul 12:32 2010

Why not -parallelizeTargets ?

To build Chromium for Mac from command line, 
$ xcodebuild -project all.xcodeproj -configuration Debug -target All

Are there any reasons not to use -parallelizeTargets option?
On my 2 quad-core CPUs machine, the option makes the build significantly faster,
without any noticeable issues.

Yuzo

--
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
ARaj | 1 Jul 13:08 2010
Picon

Selenium

Hello,

I am running Selenium test cases off Chrome and am unable to trace the
Chrome functions called by Selenium .

Here's what I did:

(1) Checked out Rev # 50671 of Chromium & built it in debug mode.

(2) Ran Selenium RC Server on my system, and wrote a small java Client
program which used the Debug Chrome Binary to enter data into a
textbox in a loop. Specifically, the values 1,2,3.. 1000000 were
entered into the textbox.

(3) As the loop above executed, I attached gdb to the chrome renderer
process ( i.e chrome --type=renderer) and placed breakpoints in
v8::script::Run().

My expectation is that, since Selenium uses JavaScript internally,
these breakpoints should get hit, but nothing happens.

Could you please tell me how this works.

Thanks!
ARaj

--

-- 
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe: 
    http://groups.google.com/a/chromium.org/group/chromium-dev

asdsad | 1 Jul 16:48 2010
Picon

generate file name based on branding

is it possible to generate a file name based on branding, eg google
chrome.sdef in one case and chromium.sdef in an other case. There is a
crude solution which involves making a copy of the same file with 2
diff names and including the files in the GYP under the appropriate
branding. Is there a more elegant solution?

--

-- 
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe: 
    http://groups.google.com/a/chromium.org/group/chromium-dev


Gmane