Use a valid /prefetch argument when launching a process.

content/public/common/prefetch_argument_win.h

Index: content/public/common/prefetch_argument_win.h
diff --git a/content/public/common/prefetch_argument_win.h b/content/public/common/prefetch_argument_win.h
new file mode 100644
index 0000000000000000000000000000000000000000..131d0d2ac36a2e7a98165ac1fa9aaf24280bbd72
--- /dev/null
+++ b/content/public/common/prefetch_argument_win.h
@@ -0,0 +1,44 @@
+// Copyright (c) 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef CONTENT_PUBLIC_COMMON_PREFETCH_ARGUMENT_WIN_H_

[jam, 2016/01/20 23:17:36]

this is is in content/public but it's not called from outside content. why is
that? my understanding from the email thread was that this needs to be called
from all places that chrome starts processes, but i don't see that done in this
change?

[fdoray, 2016/01/21 01:39:51]

This will be used outside of content [1]. I wanted to add the other call sites
in a separate CL to keep this one small. Would you prefer that I add all the
call sites as part of this CL?

[1] It will be used at least at these places:
GenerateChromeWatcherCommandLine
BrowserProcessImpl::RestartBackgroundInstance
NaClBrokerListener::OnLaunchLoaderThroughBroker
CreateServiceProcessCommandLine
auto_launch_util::EnableBackgroundStartAtLogin

[gab, 2016/01/21 20:22:59]

As much as I like smaller CLs I think it's better to put it all together in this
case. As-is this CL actually makes an invalid revision prefetching wise since
some processes still share prefetch profiles with the browser process. Plus it
introduces unused code and an unused public API.

So I'd vote for putting it all in this CL (and adding a DCHECK that a process
either has /prefetch or is the browser process (no kProcessType)).

And also, I'd like to see a browser_test that we indeed do generate multiple
prefetching profiles (i.e. a test that fails before and passes with this CL).
Feels like a simple browser_test that verifies in its body that the expected .pf
files were updated on disk should be sufficient.

+#define CONTENT_PUBLIC_COMMON_PREFETCH_ARGUMENT_WIN_H_
+
+#include "content/common/content_export.h"
+
+namespace base {
+class CommandLine;
+}  // namespace base
+
+namespace content {
+
+enum PrefetchId {
+  PREFETCH_ID_BROWSER = 0,
+  PREFETCH_ID_RENDERER,
+  PREFETCH_ID_GPU,
+  PREFETCH_ID_PPAPI,
+
+  // Prefetch ids used by the embedder should start here.
+  PREFETCH_ID_CONTENT_END,
+
+  // Default prefetch id, shared by all process types that don't have their own.
+  // It is likely that the prefetcher won't work for these process types as it
+  // won't be able to observe consistent disk reads across launches. However,
+  // having a valid prefetch argument for these process types prevents them to
+  // prevent from interfering with the prefetch profile of the browser process.
+  PREFETCH_ID_DEFAULT = 8,
+};
+
+// Adds to |command_line| a /prefetch argument with id |prefetch_id|. It has
+// been observed that when reads are consistent for 3 process launches with the
+// same prefetch argument, the prefetcher starts issuing reads in batch at
+// process launch. This is more efficient than reading a few pages at a time on-
+// demand. Because reads depend on the process type, the prefetcher can't
+// observe consistent reads if no /prefetch argument is used.
+void CONTENT_EXPORT AddWindowsPrefetchArgument(int prefetch_id,
+                                               base::CommandLine* command_line);
+
+}  // namespace content
+
+#endif  // CONTENT_PUBLIC_COMMON_PREFETCH_ARGUMENT_WIN_H_