Title: [257025] trunk/Source/WebKit
- Revision
- 257025
- Author
- ysuz...@apple.com
- Date
- 2020-02-19 18:12:53 -0800 (Wed, 19 Feb 2020)
Log Message
NetworkCache should use 4KB threshold for mmap-ed files instead of 16KB
https://bugs.webkit.org/show_bug.cgi?id=207882
Reviewed by Alex Christensen.
We found that a lot of Vectors in Membuster is holding resource content. This is because we have 16KB threshold for mmap-ed files.
If a file is smaller than 16KB, it is copied to Vector instead. But this is costly in terms of memory. If we use mmap-ed files,
it becomes named-pages instead of anonymous-pages. File-backed non-dirty named-pages have a lot of benefit.
1. The application is offering a hint that pages are file-backed. This means that OS can purge them at any time since the content can be recovered
from the disk. This is cheaper than swapping / compressing anonymous pages since just discarding works.
2. The application is offering a hint that pages have spatial locality. Purging pages in one named-pages region is better compared to purging
the same # of anonymous pages randomly. Anonymous pages are split by malloc implementation and access pattern of pages in one VA is random. On
the other hand, named-pages are accessed together because it is file, and file typically has sequential locality. And recovery of named pages are
also cheap compared to anonymous pages since OS can prefetch pages once access happens because of sequential locality of files. This tendency makes
OS like purging named pages instead of anonymous pages. In WebKit use case, this works perfectly. CachedResource typically has decoded content. So
typically WebProcess does not access SharedBuffer after the content is decoded.
This patch reduces the threshold from 16KB to page size (4KB in macOS, 16KB in iOS). This is pre-2015 behavior.
This offers 2.56% progression with 98% probability in Membuster.
* NetworkProcess/cache/NetworkCacheStorage.cpp:
(WebKit::NetworkCache::maximumInlineBodySize):
(WebKit::NetworkCache::estimateRecordsSize):
(WebKit::NetworkCache::Storage::shouldStoreBodyAsBlob):
Modified Paths
Diff
Modified: trunk/Source/WebKit/ChangeLog (257024 => 257025)
--- trunk/Source/WebKit/ChangeLog 2020-02-20 02:09:04 UTC (rev 257024)
+++ trunk/Source/WebKit/ChangeLog 2020-02-20 02:12:53 UTC (rev 257025)
@@ -1,3 +1,31 @@
+2020-02-19 Yusuke Suzuki <ysuz...@apple.com>
+
+ NetworkCache should use 4KB threshold for mmap-ed files instead of 16KB
+ https://bugs.webkit.org/show_bug.cgi?id=207882
+
+ Reviewed by Alex Christensen.
+
+ We found that a lot of Vectors in Membuster is holding resource content. This is because we have 16KB threshold for mmap-ed files.
+ If a file is smaller than 16KB, it is copied to Vector instead. But this is costly in terms of memory. If we use mmap-ed files,
+ it becomes named-pages instead of anonymous-pages. File-backed non-dirty named-pages have a lot of benefit.
+
+ 1. The application is offering a hint that pages are file-backed. This means that OS can purge them at any time since the content can be recovered
+ from the disk. This is cheaper than swapping / compressing anonymous pages since just discarding works.
+ 2. The application is offering a hint that pages have spatial locality. Purging pages in one named-pages region is better compared to purging
+ the same # of anonymous pages randomly. Anonymous pages are split by malloc implementation and access pattern of pages in one VA is random. On
+ the other hand, named-pages are accessed together because it is file, and file typically has sequential locality. And recovery of named pages are
+ also cheap compared to anonymous pages since OS can prefetch pages once access happens because of sequential locality of files. This tendency makes
+ OS like purging named pages instead of anonymous pages. In WebKit use case, this works perfectly. CachedResource typically has decoded content. So
+ typically WebProcess does not access SharedBuffer after the content is decoded.
+
+ This patch reduces the threshold from 16KB to page size (4KB in macOS, 16KB in iOS). This is pre-2015 behavior.
+ This offers 2.56% progression with 98% probability in Membuster.
+
+ * NetworkProcess/cache/NetworkCacheStorage.cpp:
+ (WebKit::NetworkCache::maximumInlineBodySize):
+ (WebKit::NetworkCache::estimateRecordsSize):
+ (WebKit::NetworkCache::Storage::shouldStoreBodyAsBlob):
+
2020-02-19 Ryosuke Niwa <rn...@webkit.org>
Crash in WebPageProxy::didStartProvisionalLoadForFrameShared
Modified: trunk/Source/WebKit/NetworkProcess/cache/NetworkCacheStorage.cpp (257024 => 257025)
--- trunk/Source/WebKit/NetworkProcess/cache/NetworkCacheStorage.cpp 2020-02-20 02:09:04 UTC (rev 257024)
+++ trunk/Source/WebKit/NetworkProcess/cache/NetworkCacheStorage.cpp 2020-02-20 02:12:53 UTC (rev 257025)
@@ -34,6 +34,7 @@
#include <mutex>
#include <wtf/Condition.h>
#include <wtf/Lock.h>
+#include <wtf/PageBlock.h>
#include <wtf/RandomNumber.h>
#include <wtf/RunLoop.h>
#include <wtf/text/CString.h>
@@ -47,8 +48,12 @@
static const char recordsDirectoryName[] = "Records";
static const char blobsDirectoryName[] = "Blobs";
static const char blobSuffix[] = "-blob";
-constexpr size_t maximumInlineBodySize { 16 * 1024 };
+static inline size_t maximumInlineBodySize()
+{
+ return WTF::pageSize();
+}
+
static double computeRecordWorth(FileTimes);
struct Storage::ReadOperation {
@@ -291,7 +296,7 @@
{
auto inlineBodyCount = recordCount - std::min(blobCount, recordCount);
auto headerSizes = recordCount * 4096;
- auto inlineBodySizes = (maximumInlineBodySize / 2) * inlineBodyCount;
+ auto inlineBodySizes = (maximumInlineBodySize() / 2) * inlineBodyCount;
return headerSizes + inlineBodySizes;
}
@@ -799,7 +804,7 @@
bool Storage::shouldStoreBodyAsBlob(const Data& bodyData)
{
- return bodyData.size() > maximumInlineBodySize;
+ return bodyData.size() > maximumInlineBodySize();
}
void Storage::dispatchWriteOperation(std::unique_ptr<WriteOperation> writeOperationPtr)
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
