Tested in chrome # 60.0.3107.5,Dev #61.0.3135.4 and Canary #61.0.3138.0 on win 7 and not able to reproduce the issue.
Steps Followed:
1. Install the process explorer and added columns "Write Bytes" & "Read Bytes".
2. Observed 6hrs Google Chrome I/O activity.

@Reporter: Could you please let me know if i have missed anything and if possible,Please create new profile without extensions and apps.Re-check once in latest builds and let us know the observations of the issue which would help us to triage the issue further.

Thanks in Advance.

Latest 61.0.3135.5 build works much better write 27Gb for 31 hours, but still I/O write champion on my computer.

Deleted: Скриншот 22.06.2017 19-13-21-555.png 379 KB

	Скриншот 22.06.2017 19-13-21-555.png 379 KB View Download

Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

6 day later

Deleted: Скриншот 27.06.2017 14-15-19-907.png 459 KB

	Скриншот 27.06.2017 14-15-19-907.png 459 KB View Download

The columns you've selected account for inter-process communication (IPC) to pass data from the main browser process to each tab's renderer process and vice versa so these big numbers are expected and normal for a multi-process application such as Chrome. If you want to measure the disk I/O, select the corresponding items on "Process Disk" tab in Process Explorer settings for the columns, which will be very low normally.

Also note, IPC volume may be increased due to extensions like Tampermpnkey or Stylish that inject userstyles/userscripts into pages. This is also normal.

Still we are unable to reproduce the issue.Some one from development team please look in to this issue.

@Reporter:Thank for the update!Could you please follow the above comments #7&8 and update us with your observations.

Thank You!

Disk activity 8Gb per one day (write to disk).

Deleted: Скриншот 29.06.2017 18-29-50-431.png 387 KB

	Скриншот 29.06.2017 18-29-50-431.png 387 KB View Download

Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Some one from Memory Allocator dev team please look in to this issue.

Thank You!

Looking at Скриншот 22.06.2017 19-13-21-555.png, "physical usage" was 97.32%.
So I think, the disk write was caused by thrashing (i.e. writing pagefile.sys).

I am not sure that here counted pagefile I/O.

To make sure whether it's paging or not, select the corresponding column in Process Explorer's "Process Memory" tab - "Page faults". Also in "Performance monitor" built-in Windows application add a new counter: "Memory" -> "Page Reads/sec" and "Page writes/sec", see https://technet.microsoft.com/en-us/library/cc938588.aspx

Ok, I compared Google Chrome result with Antivirus.
Google Chrome per 27 hours 11.9GB disk writes, 36 480 647 page faults.
Antivirus per 93 hours 3.3GB disk writes, 137 480 647 page faults.
So seems pagefile writes not counted here.

Deleted: Скриншот 07.07.2017 14-11-14-945.png 462 KB

	Скриншот 07.07.2017 14-11-14-945.png 462 KB View Download

After 4 day we have 42.9Gb disk writes and 67 442 817 page faults.

Deleted: Скриншот 10.07.2017 11-42-17-277.png 476 KB

	Скриншот 10.07.2017 11-42-17-277.png 476 KB View Download

@tasak : Could you please look in to this issue.

Thank You!

@tasak : Could you please look in to this issue.

Thank You!

Sorry. I missed. I'm trying to reproduce this.

I've already mentioned. Obviously thrashing occurred. 
E.g. chrome's private bytes 721 488K > Working set 668 236K. Looking at "Скриншот 10.07.2017 11-42-17-277.png", physical usage was 93.05%.

So because of thrashing, disk writes / page writes bytes were huge. This was expected under thrashing.

To understand what happens, I think, we need to know what pages the chrome shew. about:blank?

I would like to mark this issue as "Unconfirmed" because I have no information about how to reproduce this issue. If only talking about "thrashing", I would like to mark this issue as "WontFix".

I'm sorry. Just reproducing this issue is not difficult. Run heavy processes (i.e. spends tons of memory) and open heavy site with chrome. Thrashing will occur.

I mean, how to reproduce "chrome spends 721 488K" private bytes by browsing normal web pages".

The important thing is whether the "721 488K private bytes" was reasonable or not.

mikhail.v.gavrilov@: Could you please respond to comment #22 for further investigation.

Thanks..!!

Checked version 64.0.3262.0 (Official Build) canary (64-bit)
Current results "Disk Write Bytes" average hit 3.8GB for 26 hours this is much better when I observed before.
But I really curious what information in such amount Google Chrome write to disk. I am sure that I not download such amount of bytes from internet. So question still opened. Here may be needed additional counters integrates to browser for know more about it.

Deleted: Скриншот 09.11.2017 16-22-16-759.png 401 KB

	Скриншот 09.11.2017 16-22-16-759.png 401 KB View Download

Thank you for providing more feedback. Adding requester "mmanchala@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Would you read my comment?

I said, the disk i/o is caused by thrashing. Thrashing may occur in the paging system (if there is not sufficient physical memory or the disk access time is overly long), or in the I/O communications subsystem (especially in conflicts over internal bus access), etc.

I think, Resource Monitor's Disk Activity probably shows "PageFile.sys is actively updated."

Ok, please give me more time.
I try recheck this with disabled PageFile.sys

This is not a blink memory management issue.