* Re: [Bug 196729] New: System becomes unresponsive when swapping - Regression since 4.10.x [not found] <bug-196729-27@https.bugzilla.kernel.org/> @ 2017-08-22 22:55 ` Andrew Morton 2017-08-23 13:38 ` Michal Hocko 0 siblings, 1 reply; 5+ messages in thread From: Andrew Morton @ 2017-08-22 22:55 UTC (permalink / raw) To: linux-mm; +Cc: netwiz, bugzilla-daemon (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Tue, 22 Aug 2017 11:17:08 +0000 bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=196729 > > Bug ID: 196729 > Summary: System becomes unresponsive when swapping - Regression > since 4.10.x > Product: Memory Management > Version: 2.5 > Kernel Version: 4.11.x / 4.12.x > Hardware: All > OS: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Page Allocator > Assignee: akpm@linux-foundation.org > Reporter: netwiz@crc.id.au > Regression: No So it's "Regression: yes". More info at the bugzilla link. > I have 10Gb of RAM in this system and run Fedora 26. If I launch Cities: > Skylines with no swap space, things run well performance wise until I get an > OOM - and it all dies - which is expected. > > When I turn on swap to /dev/sda2 which resides on an SSD, I get complete > system freezes while swap is being accessed. > > The first swap was after loading a saved game, then launching kmail in the > background. This caused ~500Mb to be swapped to /dev/sda2 on an SSD. The > system froze for about 8 minutes - barely being able to move the mouse. The > HDD LED was on constantly during the entire time. > > To hopefully rule out the above glibc issue, I started the game via jemalloc - > but experienced even more severe freezes while swapping. I gave up waiting > after 13 minutes of non-responsiveness - not even being able to move the mouse > properly. > > During these hangs, I could typed into a Konsole window, and some of the > typing took 3+ minutes to display on the screen (yay for buffers?). > > I have tested this with both the default vm.swappiness values, as well as the > following: > vm.swappiness = 1 > vm.min_free_kbytes = 32768 > vm.vfs_cache_pressure = 60 > > I noticed that when I do eventually get screen updates, all 8 cpus (4 cores / > 2 threads) show 100% CPU usage - and kswapd is right up there in the process > list for CPU usage. Sadly I haven't been able to capture this information > fully yet due to said unresponsiveness. > > (more to come in comments & attachments) > > -- > You are receiving this mail because: > You are the assignee for the bug. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bug 196729] New: System becomes unresponsive when swapping - Regression since 4.10.x 2017-08-22 22:55 ` [Bug 196729] New: System becomes unresponsive when swapping - Regression since 4.10.x Andrew Morton @ 2017-08-23 13:38 ` Michal Hocko 2017-08-23 14:30 ` Steven Haigh 0 siblings, 1 reply; 5+ messages in thread From: Michal Hocko @ 2017-08-23 13:38 UTC (permalink / raw) To: netwiz; +Cc: linux-mm, Andrew Morton, bugzilla-daemon [-- Attachment #1: Type: text/plain, Size: 872 bytes --] On Tue 22-08-17 15:55:30, Andrew Morton wrote: > > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > On Tue, 22 Aug 2017 11:17:08 +0000 bugzilla-daemon@bugzilla.kernel.org wrote: [...] > Sadly I haven't been able to capture this information > > fully yet due to said unresponsiveness. Please try to collect /proc/vmstat in the bacground and provide the collected data. Something like while true do cp /proc/vmstat > vmstat.$(date +%s) sleep 1s done If the system turns out so busy that it won't be able to fork a process or write the output (which you will see by checking timestamps of files and looking for holes) then you can try the attached proggy ./read_vmstat output_file timeout output_size Note you might need to increase the mlock rlimit to lock everything into memory. -- Michal Hocko SUSE Labs [-- Attachment #2: read_vmstat.c --] [-- Type: text/x-csrc, Size: 5025 bytes --] #define _GNU_SOURCE #include <sys/types.h> #include <sys/stat.h> #include <sys/mman.h> #include <errno.h> #include <fcntl.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <limits.h> #include <unistd.h> #include <time.h> /* * A simple /proc/vmstat collector into a file. It tries hard to guarantee * that the content will get into the output file even under a strong memory * pressure. * * Usage * ./read_vmstat output_file timeout output_size * * output_file can be either a non-existing file or - for stdout * timeout - time period between two snapshots. s - seconds, ms - miliseconds * and m - minutes suffix is allowed * output_file - size of the output file. The file is preallocated and pre-filled. * * If the output reaches the end of the file it will start over overwriting the oldest * data. Each snapshot is enclosed by header and footer. * =S timestamp * [...] * E= * * Please note that your ulimit has to be sufficient to allow to mlock the code+ * all the buffers. * * This comes under GPL v2 * Copyright: Michal Hocko <mhocko@suse.cz> 2015 */ #define NS_PER_MS (1000*1000) #define NS_PER_SEC (1000*NS_PER_MS) int open_file(const char *str) { int fd; fd = open(str, O_CREAT|O_EXCL|O_RDWR, 0755); if (fd == -1) { perror("open input"); return 1; } return fd; } int read_timeout(const char *str, struct timespec *timeout) { char *end; unsigned long val; val = strtoul(str, &end, 10); if (val == ULONG_MAX) { perror("Invalid number"); return 1; } switch(*end) { case 's': timeout->tv_sec = val; break; case 'm': /* ms vs minute*/ if (*(end+1) == 's') { timeout->tv_sec = (val * NS_PER_MS) / NS_PER_SEC; timeout->tv_nsec = (val * NS_PER_MS) % NS_PER_SEC; } else { timeout->tv_sec = val*60; } break; default: fprintf(stderr, "Uknown number %s\n", str); return 1; } return 0; } size_t read_size(const char *str) { char *end; size_t val = strtoul(str, &end, 10); switch (*end) { case 'K': val <<= 10; break; case 'M': val <<= 20; break; case 'G': val <<= 30; break; } return val; } size_t dump_str(char *buffer, size_t buffer_size, size_t pos, const char *in, size_t size) { size_t i; for (i = 0; i < size; i++) { buffer[pos] = in[i]; pos = (pos + 1) % buffer_size; } return pos; } /* buffer == NULL -> stdout */ int __collect_logs(const struct timespec *timeout, char *buffer, size_t buffer_size) { char buff[4096]; /* dump to the file automatically */ time_t before, after; int in_fd = open("/proc/vmstat", O_RDONLY); size_t out_pos = 0; size_t in_pos = 0; size_t size = 0; int estimate = 0; if (in_fd == -1) { perror("open vmstat:"); return 1; } /* lock everything in */ if (mlockall(MCL_CURRENT) == -1) { perror("mlockall. Continuing anyway"); } while (1) { before = time(NULL); size = snprintf(buff, sizeof(buff), "=S %lu\n", before); lseek(in_fd, 0, SEEK_SET); size += read(in_fd, buff + size, sizeof(buff) - size); size += snprintf(buff + size, sizeof(buff) - size, "E=\n"); if (buffer && !estimate) { printf("Estimated %d entries fit to the buffer\n", buffer_size/size); estimate = 1; } /* Dump to stdout */ if (!buffer) { printf("%s", buff); } else { size_t pos; pos = dump_str(buffer, buffer_size, out_pos, buff, size); if (pos < out_pos) fprintf(stderr, "%lu: Buffer wrapped\n", before); out_pos = pos; } after = time(NULL); if (after - before > 2) { fprintf(stderr, "%d: Snapshoting took %d!!!\n", before, after-before); } if (nanosleep(timeout, NULL) == -1) if (errno == EINTR) return 0; /* kick in the flushing */ if (buffer) msync(buffer, buffer_size, MS_ASYNC); } } int collect_logs(int fd, const struct timespec *timeout, size_t buffer_size) { unsigned char *buffer = NULL; if (fd != -1) { if (ftruncate(fd, buffer_size) == -1) { perror("ftruncate"); return 1; } if (fallocate(fd, 0, 0, buffer_size) && errno != EOPNOTSUPP) { perror("fallocate"); return 1; } /* commit it to the disk */ sync(); buffer = mmap(NULL, buffer_size, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_POPULATE, fd, 0); if (buffer == MAP_FAILED) { perror("mmap"); return 1; } } return __collect_logs(timeout, buffer, buffer_size); } int main(int argc, char **argv) { struct timespec timeout = {.tv_sec = 1}; int fd = -1; size_t buffer_size = 10UL<<20; if (argc > 1) { /* output file */ if (strcmp(argv[1], "-")) { fd = open_file(argv[1]); if (fd == -1) return 1; } /* timeout */ if (argc > 2) { if (read_timeout(argv[2], &timeout)) return 1; /* buffer size */ if (argc > 3) { buffer_size = read_size(argv[3]); if (buffer_size == -1UL) return 1; } } } printf("file:%s timeout:%lu.%lus buffer_size:%llu\n", (fd == -1)? "stdout" : argv[1], timeout.tv_sec, timeout.tv_nsec / NS_PER_MS, buffer_size); return collect_logs(fd, &timeout, buffer_size); } ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bug 196729] New: System becomes unresponsive when swapping - Regression since 4.10.x 2017-08-23 13:38 ` Michal Hocko @ 2017-08-23 14:30 ` Steven Haigh 2017-08-24 12:41 ` Michal Hocko 0 siblings, 1 reply; 5+ messages in thread From: Steven Haigh @ 2017-08-23 14:30 UTC (permalink / raw) To: Michal Hocko; +Cc: linux-mm, Andrew Morton, bugzilla-daemon [-- Attachment #1.1: Type: text/plain, Size: 3772 bytes --] On Wednesday, 23 August 2017 11:38:48 PM AEST Michal Hocko wrote: > On Tue 22-08-17 15:55:30, Andrew Morton wrote: > > (switched to email. Please respond via emailed reply-to-all, not via the > > bugzilla web interface). > > > On Tue, 22 Aug 2017 11:17:08 +0000 bugzilla-daemon@bugzilla.kernel.org wrote: > [...] > > > Sadly I haven't been able to capture this information > > > > > fully yet due to said unresponsiveness. > > Please try to collect /proc/vmstat in the bacground and provide the > collected data. Something like > > while true > do > cp /proc/vmstat > vmstat.$(date +%s) > sleep 1s > done > > If the system turns out so busy that it won't be able to fork a process > or write the output (which you will see by checking timestamps of files > and looking for holes) then you can try the attached proggy > ./read_vmstat output_file timeout output_size > > Note you might need to increase the mlock rlimit to lock everything into > memory. Thanks Michal, I have upgraded PCs since I initially put together this data - however I was able to get strange behaviour by pulling out an 8Gb RAM stick in my new system - leaving it with only 8Gb of RAM. All these tests are performed with Fedora 26 and kernel 4.12.8-300.fc26.x86_64 I have attached 3 files with output. 8Gb-noswap.tar.gz contains the output of /proc/vmstat running on 8Gb of RAM with no swap. Under this scenario, I was expecting the OOM reaper to just kill the game when memory allocated became too high for the amount of physical RAM. Interestingly, you'll notice a massive hang in the output before the game is terminated. I didn't see this before. 8Gb-swap-on-file.tar.gz contains the output of /proc/vmstat still with 8Gb of RAM - but creating a file with swap on the PCIe SSD /swapfile with size 8Gb via: # dd if=/dev/zero of=/swapfile bs=1G count=8 # mkswap /swapfile # swapon /swapfile Some times (all in UTC+10): 23:58:30 - Start loading the saved game 23:59:38 - Load ok, all running fine 00:00:15 - Load Chrome 00:01:00 - Quit the game The game seemed to run ok with no real issue - and a lot was swapped to the swap file. I'm wondering if it was purely the speed of the PCIe SSD that caused this appearance - as the creation of the file with dd completed at ~1.4GB/sec. 8Gb-swap-on-ssd.tar.gz contains adding a 32Gb SATA based SSD to the system and using the entire block device as swap via: # mkswap -f /dev/sda # swapon /dev/sda There are many pauses and unresponsiveness issues while this was loading - however we eventually got there. Some timings (all in UTC+10 again): 00:06:33 - Load the saved game 00:11:22 - Saved game loaded - somewhat responsive 00:12:00 - Load Chrome 00:13:07 - Quit the game + chrome For the sake of information, the following is a speed test on the SSD in question: # dd if=/dev/zero of=/dev/sda bs=1M count=8192 conv=fsync 8192+0 records in 8192+0 records out 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 44.923 s, 191 MB/s # dd if=/dev/sda of=/dev/null bs=1M count=8192 conv=fsync dd: fsync failed for '/dev/null': Invalid argument 8192+0 records in 8192+0 records out 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 30.7414 s, 279 MB/s Running the game on the exact same system with 16Gb of RAM and no swap works perfectly - even with multitasking - as we never end up filling physical RAM. As there is some data missing though, should I still attempt to compile + run the program provided? I'm not quite clear on the mlock rlimit mention - I haven't really had to debug anything like this before. -- Steven Haigh 📧 netwiz@crc.id.au 💻 http://www.crc.id.au 📞 +61 (3) 9001 6090 📱 0412 935 897 [-- Attachment #1.2: 8Gb-noswap.tar.gz --] [-- Type: application/x-compressed-tar, Size: 19093 bytes --] [-- Attachment #1.3: 8Gb-swap-on-file.tar.gz --] [-- Type: application/x-compressed-tar, Size: 43131 bytes --] [-- Attachment #1.4: 8Gb-swap-on-ssd.tar.gz --] [-- Type: application/x-compressed-tar, Size: 98509 bytes --] [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bug 196729] New: System becomes unresponsive when swapping - Regression since 4.10.x 2017-08-23 14:30 ` Steven Haigh @ 2017-08-24 12:41 ` Michal Hocko 2017-08-24 14:19 ` Steven Haigh 0 siblings, 1 reply; 5+ messages in thread From: Michal Hocko @ 2017-08-24 12:41 UTC (permalink / raw) To: Steven Haigh; +Cc: linux-mm, Andrew Morton, bugzilla-daemon On Thu 24-08-17 00:30:40, Steven Haigh wrote: > On Wednesday, 23 August 2017 11:38:48 PM AEST Michal Hocko wrote: > > On Tue 22-08-17 15:55:30, Andrew Morton wrote: > > > (switched to email. Please respond via emailed reply-to-all, not via the > > > bugzilla web interface). > > > > > On Tue, 22 Aug 2017 11:17:08 +0000 bugzilla-daemon@bugzilla.kernel.org > wrote: > > [...] > > > > > Sadly I haven't been able to capture this information > > > > > > > fully yet due to said unresponsiveness. > > > > Please try to collect /proc/vmstat in the bacground and provide the > > collected data. Something like > > > > while true > > do > > cp /proc/vmstat > vmstat.$(date +%s) > > sleep 1s > > done > > > > If the system turns out so busy that it won't be able to fork a process > > or write the output (which you will see by checking timestamps of files > > and looking for holes) then you can try the attached proggy > > ./read_vmstat output_file timeout output_size > > > > Note you might need to increase the mlock rlimit to lock everything into > > memory. > > Thanks Michal, > > I have upgraded PCs since I initially put together this data - however I was > able to get strange behaviour by pulling out an 8Gb RAM stick in my new system > - leaving it with only 8Gb of RAM. > > All these tests are performed with Fedora 26 and kernel 4.12.8-300.fc26.x86_64 > > I have attached 3 files with output. > > 8Gb-noswap.tar.gz contains the output of /proc/vmstat running on 8Gb of RAM > with no swap. Under this scenario, I was expecting the OOM reaper to just kill > the game when memory allocated became too high for the amount of physical RAM. > Interestingly, you'll notice a massive hang in the output before the game is > terminated. I didn't see this before. I have checked few gaps. E.g. vmstat.1503496391 vmstat.1503496451 which is one minute. The most notable thing is that there are only very few pagecache pages [base] [diff] nr_active_file 1641 3345 nr_inactive_file 1630 4787 So there is not much to reclaim without swap. The more important thing is that we keep reclaiming and refaulting that memory workingset_activate 5905591 1616391 workingset_refault 33412538 10302135 pgactivate 42279686 13219593 pgdeactivate 48175757 14833350 pgscan_kswapd 379431778 126407849 pgsteal_kswapd 49751559 13322930 so we are effectivelly trashing over the very small amount of reclaimable memory. This is something that we cannot detect right now. It is even questionable whether the OOM killer would be an appropriate action. Your system has recovered and then it is always hard to decide whether a disruptive action is more appropriate. One minute of unresponsiveness is certainly annoying though. Your system is obviously under provisioned to load you want to run obviously. It is quite interesting to see that we do not really have too many direct reclaimers during this time period allocstall_normal 30 1 allocstall_movable 490 88 pgscan_direct_throttle 0 0 pgsteal_direct 24434 4069 pgscan_direct 38678 5868 > 8Gb-swap-on-file.tar.gz contains the output of /proc/vmstat still with 8Gb of > RAM - but creating a file with swap on the PCIe SSD /swapfile with size 8Gb > via: > # dd if=/dev/zero of=/swapfile bs=1G count=8 > # mkswap /swapfile > # swapon /swapfile > > Some times (all in UTC+10): > 23:58:30 - Start loading the saved game > 23:59:38 - Load ok, all running fine > 00:00:15 - Load Chrome > 00:01:00 - Quit the game > > The game seemed to run ok with no real issue - and a lot was swapped to the > swap file. I'm wondering if it was purely the speed of the PCIe SSD that > caused this appearance - as the creation of the file with dd completed at > ~1.4GB/sec. Swap IO tends to be really scattered and the IO performance is not really great even on a fast storage AFAIK. Anyway your original report sounded like a regression. Were you able to run the _same_ workload on an older kernel without these issues? -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bug 196729] New: System becomes unresponsive when swapping - Regression since 4.10.x 2017-08-24 12:41 ` Michal Hocko @ 2017-08-24 14:19 ` Steven Haigh 0 siblings, 0 replies; 5+ messages in thread From: Steven Haigh @ 2017-08-24 14:19 UTC (permalink / raw) To: Michal Hocko; +Cc: linux-mm, Andrew Morton, bugzilla-daemon [-- Attachment #1: Type: text/plain, Size: 5652 bytes --] On Thursday, 24 August 2017 10:41:39 PM AEST Michal Hocko wrote: > On Thu 24-08-17 00:30:40, Steven Haigh wrote: > > On Wednesday, 23 August 2017 11:38:48 PM AEST Michal Hocko wrote: > > > On Tue 22-08-17 15:55:30, Andrew Morton wrote: > > > > (switched to email. Please respond via emailed reply-to-all, not via > > > > the > > > > bugzilla web interface). > > > > > > > > On Tue, 22 Aug 2017 11:17:08 +0000 bugzilla-daemon@bugzilla.kernel.org > > > > wrote: > > > [...] > > > > > > > Sadly I haven't been able to capture this information > > > > > > > > > fully yet due to said unresponsiveness. > > > > > > Please try to collect /proc/vmstat in the bacground and provide the > > > collected data. Something like > > > > > > while true > > > do > > > > > > cp /proc/vmstat > vmstat.$(date +%s) > > > sleep 1s > > > > > > done > > > > > > If the system turns out so busy that it won't be able to fork a process > > > or write the output (which you will see by checking timestamps of files > > > and looking for holes) then you can try the attached proggy > > > ./read_vmstat output_file timeout output_size > > > > > > Note you might need to increase the mlock rlimit to lock everything into > > > memory. > > > > Thanks Michal, > > > > I have upgraded PCs since I initially put together this data - however I > > was able to get strange behaviour by pulling out an 8Gb RAM stick in my > > new system - leaving it with only 8Gb of RAM. > > > > All these tests are performed with Fedora 26 and kernel > > 4.12.8-300.fc26.x86_64 > > > > I have attached 3 files with output. > > > > 8Gb-noswap.tar.gz contains the output of /proc/vmstat running on 8Gb of > > RAM > > with no swap. Under this scenario, I was expecting the OOM reaper to just > > kill the game when memory allocated became too high for the amount of > > physical RAM. Interestingly, you'll notice a massive hang in the output > > before the game is terminated. I didn't see this before. > > I have checked few gaps. E.g. vmstat.1503496391 vmstat.1503496451 which > is one minute. The most notable thing is that there are only very few > pagecache pages > [base] [diff] > nr_active_file 1641 3345 > nr_inactive_file 1630 4787 > > So there is not much to reclaim without swap. The more important thing > is that we keep reclaiming and refaulting that memory > > workingset_activate 5905591 1616391 > workingset_refault 33412538 10302135 > pgactivate 42279686 13219593 > pgdeactivate 48175757 14833350 > > pgscan_kswapd 379431778 126407849 > pgsteal_kswapd 49751559 13322930 > > so we are effectivelly trashing over the very small amount of > reclaimable memory. This is something that we cannot detect right now. > It is even questionable whether the OOM killer would be an appropriate > action. Your system has recovered and then it is always hard to decide > whether a disruptive action is more appropriate. One minute of > unresponsiveness is certainly annoying though. Your system is obviously > under provisioned to load you want to run obviously. > > It is quite interesting to see that we do not really have too many > direct reclaimers during this time period > allocstall_normal 30 1 > allocstall_movable 490 88 > pgscan_direct_throttle 0 0 > pgsteal_direct 24434 4069 > pgscan_direct 38678 5868 Yes, I understand that the system is really not suitable - however I believe the test is useful - even from an informational point of view :) > > 8Gb-swap-on-file.tar.gz contains the output of /proc/vmstat still with 8Gb > > of RAM - but creating a file with swap on the PCIe SSD /swapfile with > > size 8Gb> > > via: > > # dd if=/dev/zero of=/swapfile bs=1G count=8 > > # mkswap /swapfile > > # swapon /swapfile > > > > Some times (all in UTC+10): > > 23:58:30 - Start loading the saved game > > 23:59:38 - Load ok, all running fine > > 00:00:15 - Load Chrome > > 00:01:00 - Quit the game > > > > The game seemed to run ok with no real issue - and a lot was swapped to > > the > > swap file. I'm wondering if it was purely the speed of the PCIe SSD that > > caused this appearance - as the creation of the file with dd completed at > > ~1.4GB/sec. > > Swap IO tends to be really scattered and the IO performance is not really > great even on a fast storage AFAIK. > > Anyway your original report sounded like a regression. Were you able to > run the _same_ workload on an older kernel without these issues? When I try the same tests with swap on an SSD under kernel 4.10.x (I believe the latest I tried was 4.10.25?) - then swap using the SSD did not cause any issues or periods of system unresponsiveness. The file attached in the original bug report "vmstat-4.10.17-10Gb.log" was taken on my old system with 10Gb of RAM - and there were no significant pauses while swapping. I do find it interesting that the newer '8Gb-swap-on-file.tar.gz' does not show any issues. I wonder if it would be helpful to attempt the same using a file on the SSD that was a swap disk in the '8Gb-swap-on-ssd.tar.gz' so we have a constant device - but with a file on the SSD instead of the entire block device. That would at least expose any issues on the same device in file vs block mode? Or maybe even if there's a difference just having the file on a much (much!) faster drive? -- Steven Haigh 📧 netwiz@crc.id.au 💻 http://www.crc.id.au 📞 +61 (3) 9001 6090 📱 0412 935 897 [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-08-24 14:20 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-196729-27@https.bugzilla.kernel.org/>
2017-08-22 22:55 ` [Bug 196729] New: System becomes unresponsive when swapping - Regression since 4.10.x Andrew Morton
2017-08-23 13:38 ` Michal Hocko
2017-08-23 14:30 ` Steven Haigh
2017-08-24 12:41 ` Michal Hocko
2017-08-24 14:19 ` Steven Haigh
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox