Re: Creating compressed backing_store as swapfile

On 11/5/2018 11:53 AM, valdis.kletni...@vt.edu wrote: On Mon, 05 Nov 2018 11:28:49 -0500, "Austin S. Hemmelgarn" said: Also, it's probably worth noting that BTRFS doesn't need to decompress the entire file to read or write blocks in the middle, it splits the file into 1

Re: Creating compressed backing_store as swapfile

On 11/5/2018 11:53 AM, valdis.kletni...@vt.edu wrote: On Mon, 05 Nov 2018 11:28:49 -0500, "Austin S. Hemmelgarn" said: Also, it's probably worth noting that BTRFS doesn't need to decompress the entire file to read or write blocks in the middle, it splits the file into 1

Re: POSIX violation by writeback error

On 2018-09-05 04:37, 焦晓冬 wrote: On Wed, Sep 5, 2018 at 4:04 PM Rogier Wolff wrote: On Wed, Sep 05, 2018 at 09:39:58AM +0200, Martin Steigerwald wrote: Rogier Wolff - 05.09.18, 09:08: So when a mail queuer puts mail the mailq files and the mail processor can get them out of there intact,

Re: POSIX violation by writeback error

On 2018-09-05 04:37, 焦晓冬 wrote: On Wed, Sep 5, 2018 at 4:04 PM Rogier Wolff wrote: On Wed, Sep 05, 2018 at 09:39:58AM +0200, Martin Steigerwald wrote: Rogier Wolff - 05.09.18, 09:08: So when a mail queuer puts mail the mailq files and the mail processor can get them out of there intact,

Re: [PATCH 1/2] x86: x86_64_defconfig: Enable KSM.

On 2018-06-14 18:50, Daniel Díaz wrote: As per the documentation, Kernel Samepage Merging (available since 2.6.32) is a memory-saving de-duplication feature, enabled by CONFIG_KSM=y and activated via sysfs. More information can be found here:

Re: [PATCH 1/2] x86: x86_64_defconfig: Enable KSM.

On 2018-06-14 18:50, Daniel Díaz wrote: As per the documentation, Kernel Samepage Merging (available since 2.6.32) is a memory-saving de-duplication feature, enabled by CONFIG_KSM=y and activated via sysfs. More information can be found here:

Re: Read-protected UEFI variables

On 2018-02-14 08:21, Benjamin Drung wrote: Am Mittwoch, den 14.02.2018, 13:09 + schrieb Ard Biesheuvel: On 14 February 2018 at 12:52, Benjamin Drung wrote: Hi, I am exploring the possibility to store SSH and other keys in UEFI variables for systems that

Re: Read-protected UEFI variables

On 2018-02-14 08:21, Benjamin Drung wrote: Am Mittwoch, den 14.02.2018, 13:09 + schrieb Ard Biesheuvel: On 14 February 2018 at 12:52, Benjamin Drung wrote: Hi, I am exploring the possibility to store SSH and other keys in UEFI variables for systems that do not have persistent storage.

Re: [PATCH] efi: make EFI a menuconfig to ease disabling it all

On 2017-12-15 12:24, Vincent Legoll wrote: Hello, This looks fine to me. Ard? Doesn't this break existing configs? Would adding a "default yes" on the new menuconfig be OK. If yes, I'd respin it for a v2 Alternatively, would it not make some degree of sense to just turn the CONFIG_EFI

Re: [PATCH] efi: make EFI a menuconfig to ease disabling it all

On 2017-12-15 12:24, Vincent Legoll wrote: Hello, This looks fine to me. Ard? Doesn't this break existing configs? Would adding a "default yes" on the new menuconfig be OK. If yes, I'd respin it for a v2 Alternatively, would it not make some degree of sense to just turn the CONFIG_EFI

Re: [PATCH v5 3/5] btrfs: Add zstd support

On 2017-08-09 22:39, Nick Terrell wrote: Add zstd compression and decompression support to BtrFS. zstd at its fastest level compresses almost as well as zlib, while offering much faster compression and decompression, approaching lzo speeds. I benchmarked btrfs with zstd compression against no

Re: [PATCH v5 3/5] btrfs: Add zstd support

On 2017-08-09 22:39, Nick Terrell wrote: Add zstd compression and decompression support to BtrFS. zstd at its fastest level compresses almost as well as zlib, while offering much faster compression and decompression, approaching lzo speeds. I benchmarked btrfs with zstd compression against no

Re: [PATCH v5 2/5] lib: Add zstd modules

On 2017-08-10 15:25, Hugo Mills wrote: On Thu, Aug 10, 2017 at 01:41:21PM -0400, Chris Mason wrote: On 08/10/2017 04:30 AM, Eric Biggers wrote: Theses benchmarks are misleading because they compress the whole file as a single stream without resetting the dictionary, which isn't how data will

Re: [PATCH v5 2/5] lib: Add zstd modules

On 2017-08-10 15:25, Hugo Mills wrote: On Thu, Aug 10, 2017 at 01:41:21PM -0400, Chris Mason wrote: On 08/10/2017 04:30 AM, Eric Biggers wrote: Theses benchmarks are misleading because they compress the whole file as a single stream without resetting the dictionary, which isn't how data will

Re: [PATCH v5 2/5] lib: Add zstd modules

On 2017-08-10 13:24, Eric Biggers wrote: On Thu, Aug 10, 2017 at 07:32:18AM -0400, Austin S. Hemmelgarn wrote: On 2017-08-10 04:30, Eric Biggers wrote: On Wed, Aug 09, 2017 at 07:35:53PM -0700, Nick Terrell wrote: It can compress at speeds approaching lz4, and quality approaching lzma

Re: [PATCH v5 2/5] lib: Add zstd modules

On 2017-08-10 13:24, Eric Biggers wrote: On Thu, Aug 10, 2017 at 07:32:18AM -0400, Austin S. Hemmelgarn wrote: On 2017-08-10 04:30, Eric Biggers wrote: On Wed, Aug 09, 2017 at 07:35:53PM -0700, Nick Terrell wrote: It can compress at speeds approaching lz4, and quality approaching lzma

Re: [PATCH v5 2/5] lib: Add zstd modules

On 2017-08-10 07:32, Austin S. Hemmelgarn wrote: On 2017-08-10 04:30, Eric Biggers wrote: On Wed, Aug 09, 2017 at 07:35:53PM -0700, Nick Terrell wrote: It can compress at speeds approaching lz4, and quality approaching lzma. Well, for a very loose definition of "approaching", and

Re: [PATCH v5 2/5] lib: Add zstd modules

On 2017-08-10 07:32, Austin S. Hemmelgarn wrote: On 2017-08-10 04:30, Eric Biggers wrote: On Wed, Aug 09, 2017 at 07:35:53PM -0700, Nick Terrell wrote: It can compress at speeds approaching lz4, and quality approaching lzma. Well, for a very loose definition of "approaching", and

Re: [PATCH v5 2/5] lib: Add zstd modules

On 2017-08-10 04:30, Eric Biggers wrote: On Wed, Aug 09, 2017 at 07:35:53PM -0700, Nick Terrell wrote: It can compress at speeds approaching lz4, and quality approaching lzma. Well, for a very loose definition of "approaching", and certainly not at the same time. I doubt there's a use case

Re: [PATCH v5 2/5] lib: Add zstd modules

On 2017-08-10 04:30, Eric Biggers wrote: On Wed, Aug 09, 2017 at 07:35:53PM -0700, Nick Terrell wrote: It can compress at speeds approaching lz4, and quality approaching lzma. Well, for a very loose definition of "approaching", and certainly not at the same time. I doubt there's a use case

Re: bcache with existing ext4 filesystem

On 2017-07-26 13:41, Eric Wheeler wrote: On Wed, 26 Jul 2017, Pavel Machek wrote: Hi! Unfortunately, that would mean shifting 400GB data 8KB forward, and compatibility problems. So I'd prefer adding bcache superblock into the reserved space, so I can have caching _and_ compatibility with

Re: bcache with existing ext4 filesystem

On 2017-07-26 13:41, Eric Wheeler wrote: On Wed, 26 Jul 2017, Pavel Machek wrote: Hi! Unfortunately, that would mean shifting 400GB data 8KB forward, and compatibility problems. So I'd prefer adding bcache superblock into the reserved space, so I can have caching _and_ compatibility with

Re: [PATCH v3 0/4] Add xxhash and zstd modules

On 2017-07-22 07:35, Adam Borowski wrote: On Fri, Jul 21, 2017 at 11:56:21AM -0400, Austin S. Hemmelgarn wrote: On 2017-07-20 17:27, Nick Terrell wrote: This patch set adds xxhash, zstd compression, and zstd decompression modules. It also adds zstd support to BtrFS and SquashFS. Each patch

Re: [PATCH v3 0/4] Add xxhash and zstd modules

On 2017-07-22 07:35, Adam Borowski wrote: On Fri, Jul 21, 2017 at 11:56:21AM -0400, Austin S. Hemmelgarn wrote: On 2017-07-20 17:27, Nick Terrell wrote: This patch set adds xxhash, zstd compression, and zstd decompression modules. It also adds zstd support to BtrFS and SquashFS. Each patch

Re: [PATCH v3 0/4] Add xxhash and zstd modules

and had runtime testing running for about 18 hours now with no issues, so you can add: Tested-by: Austin S. Hemmelgarn <ahferro...@gmail.com> For patch 1, I've only compile tested it, but had no issues and got no warnings about it when booting to test 2-4. For patch 4, I've compile

Re: [PATCH v3 0/4] Add xxhash and zstd modules

and had runtime testing running for about 18 hours now with no issues, so you can add: Tested-by: Austin S. Hemmelgarn For patch 1, I've only compile tested it, but had no issues and got no warnings about it when booting to test 2-4. For patch 4, I've compile tested it and done some really

Re: [PATCH v3 0/4] Add xxhash and zstd modules

On 2017-07-21 07:16, Austin S. Hemmelgarn wrote: On 2017-07-20 17:27, Nick Terrell wrote: Well this is embarrassing, forgot to type anything before hitting send... Hi all, This patch set adds xxhash, zstd compression, and zstd decompression modules. It also adds zstd support to BtrFS

Re: [PATCH v3 0/4] Add xxhash and zstd modules

On 2017-07-21 07:16, Austin S. Hemmelgarn wrote: On 2017-07-20 17:27, Nick Terrell wrote: Well this is embarrassing, forgot to type anything before hitting send... Hi all, This patch set adds xxhash, zstd compression, and zstd decompression modules. It also adds zstd support to BtrFS

Re: [PATCH v3 0/4] Add xxhash and zstd modules

On 2017-07-20 17:27, Nick Terrell wrote: Hi all, This patch set adds xxhash, zstd compression, and zstd decompression modules. It also adds zstd support to BtrFS and SquashFS. Each patch has relevant summaries, benchmarks, and tests. Best, Nick Terrell Changelog: v1 -> v2: - Make pointer in

Re: [PATCH v3 0/4] Add xxhash and zstd modules

On 2017-07-20 17:27, Nick Terrell wrote: Hi all, This patch set adds xxhash, zstd compression, and zstd decompression modules. It also adds zstd support to BtrFS and SquashFS. Each patch has relevant summaries, benchmarks, and tests. Best, Nick Terrell Changelog: v1 -> v2: - Make pointer in

Re: [PATCH v2 3/4] btrfs: Add zstd support

On 2017-07-07 23:07, Adam Borowski wrote: On Sat, Jul 08, 2017 at 01:40:18AM +0200, Adam Borowski wrote: On Fri, Jul 07, 2017 at 11:17:49PM +, Nick Terrell wrote: On 7/6/17, 9:32 AM, "Adam Borowski" wrote: Got a reproducible crash on amd64: Thanks for the bug

Re: [PATCH v2 3/4] btrfs: Add zstd support

On 2017-07-07 23:07, Adam Borowski wrote: On Sat, Jul 08, 2017 at 01:40:18AM +0200, Adam Borowski wrote: On Fri, Jul 07, 2017 at 11:17:49PM +, Nick Terrell wrote: On 7/6/17, 9:32 AM, "Adam Borowski" wrote: Got a reproducible crash on amd64: Thanks for the bug report Adam! I'm looking

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On 2017-05-13 19:17, PGNet Dev wrote: On 5/13/17 3:15 PM, Valentin Vidic wrote: Try booting without 'hpet=force,verbose clocksource=hpet' and it should select xen by default: Nope. Well, not quite ... With both 'hpet=force,verbose clocksource=hpet' removed, I end up with

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On 2017-05-13 19:17, PGNet Dev wrote: On 5/13/17 3:15 PM, Valentin Vidic wrote: Try booting without 'hpet=force,verbose clocksource=hpet' and it should select xen by default: Nope. Well, not quite ... With both 'hpet=force,verbose clocksource=hpet' removed, I end up with

Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division

On 2017-04-08 17:07, Adam Borowski wrote: Unbreaks ARM and possibly other 32-bit architectures. Fixes: 7d0ef8b4d: Btrfs: update scrub_parity to use u64 stripe_len Reported-by: Icenowy Zheng Signed-off-by: Adam Borowski --- You'd probably want to squash

Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division

On 2017-04-08 17:07, Adam Borowski wrote: Unbreaks ARM and possibly other 32-bit architectures. Fixes: 7d0ef8b4d: Btrfs: update scrub_parity to use u64 stripe_len Reported-by: Icenowy Zheng Signed-off-by: Adam Borowski --- You'd probably want to squash this with Liu's commit, to be nice to

Re: [PATCH 00/24] Kernel lockdown

On 2017-04-05 16:14, David Howells wrote: These patches provide a facility by which a variety of avenues by which userspace can feasibly modify the running kernel image can be locked down. These include: (*) No unsigned modules and no modules for which can't validate the signature. (*)

Re: [PATCH 00/24] Kernel lockdown

On 2017-04-05 16:14, David Howells wrote: These patches provide a facility by which a variety of avenues by which userspace can feasibly modify the running kernel image can be locked down. These include: (*) No unsigned modules and no modules for which can't validate the signature. (*)

Re: [PATCH linux-next V2] tty: Disable default console blanking interval

On 2017-03-22 21:32, Scot Doyle wrote: On Wed, 22 Mar 2017, Tim Gardner wrote: BugLink: http://bugs.launchpad.net/bugs/869017 Console blanking is not enabling DPMS power saving (thereby negating any power-saving benefit), and is simply turning the screen content blank. This means that any

Re: [PATCH linux-next V2] tty: Disable default console blanking interval

On 2017-03-22 21:32, Scot Doyle wrote: On Wed, 22 Mar 2017, Tim Gardner wrote: BugLink: http://bugs.launchpad.net/bugs/869017 Console blanking is not enabling DPMS power saving (thereby negating any power-saving benefit), and is simply turning the screen content blank. This means that any

Re: [PATCH linux-next] tty: Disable default console blanking interval

On 2017-03-22 09:50, Tim Gardner wrote: BugLink: http://bugs.launchpad.net/bugs/869017 Signed-off-by: Tim Gardner Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Adam Borowski Cc: Scot Doyle

Re: [PATCH linux-next] tty: Disable default console blanking interval

On 2017-03-22 09:50, Tim Gardner wrote: BugLink: http://bugs.launchpad.net/bugs/869017 Signed-off-by: Tim Gardner Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Adam Borowski Cc: Scot Doyle --- I'm not particularly knowledgable about console issues. Is a blaknking interval relevant in a post

Re: When will Linux support M2 on RAID ?

On 2017-03-07 10:15, Christoph Hellwig wrote: On Tue, Mar 07, 2017 at 09:50:22AM -0500, Austin S. Hemmelgarn wrote: He's referring to the RAID mode most modern Intel chipsets have, which (last I checked) Linux does not support completely and many OEM's are setting by default on new systems

Re: When will Linux support M2 on RAID ?

On 2017-03-07 10:15, Christoph Hellwig wrote: On Tue, Mar 07, 2017 at 09:50:22AM -0500, Austin S. Hemmelgarn wrote: He's referring to the RAID mode most modern Intel chipsets have, which (last I checked) Linux does not support completely and many OEM's are setting by default on new systems

Re: When will Linux support M2 on RAID ?

On 2017-03-06 23:52, Christoph Hellwig wrote: On Sun, Mar 05, 2017 at 06:09:42PM -0800, David F. wrote: More and more systems are coming with M2 on RAID and Linux doesn't work unless you change the system out of RAID mode. This is becoming more and more of a problem. What is the status of

Re: When will Linux support M2 on RAID ?

On 2017-03-06 23:52, Christoph Hellwig wrote: On Sun, Mar 05, 2017 at 06:09:42PM -0800, David F. wrote: More and more systems are coming with M2 on RAID and Linux doesn't work unless you change the system out of RAID mode. This is becoming more and more of a problem. What is the status of

Re: Dell XPS13: MCE (Hardware Error) reported

On 2017-01-31 10:29, Paul Menzel wrote: Dear Borislav, dear Mario, On 01/27/17 18:16, mario.limoncie...@dell.com wrote: -Original Message- From: Borislav Petkov [mailto:b...@alien8.de] Sent: Friday, January 27, 2017 11:11 AM To: Paul Menzel Cc: Ashok Raj

Re: Dell XPS13: MCE (Hardware Error) reported

On 2017-01-31 10:29, Paul Menzel wrote: Dear Borislav, dear Mario, On 01/27/17 18:16, mario.limoncie...@dell.com wrote: -Original Message- From: Borislav Petkov [mailto:b...@alien8.de] Sent: Friday, January 27, 2017 11:11 AM To: Paul Menzel Cc: Ashok Raj ; Linux Kernel Mailing List ;

Re: [PATCH v2] Add a "nosymlinks" mount option.

On 2016-11-16 16:18, Mattias Nissler wrote: I understand that silence suggests there's little interest, but here's some new information I discovered today that may justify to reconsider the patch: The BSDs already have exactly what I propose, the mount option is called "nosymfollow" there:

Re: [PATCH v2] Add a "nosymlinks" mount option.

On 2016-11-16 16:18, Mattias Nissler wrote: I understand that silence suggests there's little interest, but here's some new information I discovered today that may justify to reconsider the patch: The BSDs already have exactly what I propose, the mount option is called "nosymfollow" there:

Re: [PATCH] f2fs: support multiple devices

On 2016-11-09 21:29, Qu Wenruo wrote: At 11/10/2016 06:57 AM, Andreas Dilger wrote: On Nov 9, 2016, at 1:56 PM, Jaegeuk Kim wrote: This patch implements multiple devices support for f2fs. Given multiple devices by mkfs.f2fs, f2fs shows them entirely as one big volume

Re: [PATCH] f2fs: support multiple devices

On 2016-11-09 21:29, Qu Wenruo wrote: At 11/10/2016 06:57 AM, Andreas Dilger wrote: On Nov 9, 2016, at 1:56 PM, Jaegeuk Kim wrote: This patch implements multiple devices support for f2fs. Given multiple devices by mkfs.f2fs, f2fs shows them entirely as one big volume under one f2fs

Re: [PATCH 2/2] kbuild: add -fno-PIE

On 2016-11-04 10:39, Markus Trippelsdorf wrote: On 2016.11.04 at 15:24 +0100, Sebastian Andrzej Siewior wrote: On 2016-11-04 07:37:02 [-0400], Austin S. Hemmelgarn wrote: clued enough to have known better. Reassigning bug reports in question from gcc-6 to linux is beyond stupid; Balint

Re: [PATCH 2/2] kbuild: add -fno-PIE

On 2016-11-04 10:39, Markus Trippelsdorf wrote: On 2016.11.04 at 15:24 +0100, Sebastian Andrzej Siewior wrote: On 2016-11-04 07:37:02 [-0400], Austin S. Hemmelgarn wrote: clued enough to have known better. Reassigning bug reports in question from gcc-6 to linux is beyond stupid; Balint

Re: [PATCH 2/2] kbuild: add -fno-PIE

On 2016-11-04 10:24, Sebastian Andrzej Siewior wrote: On 2016-11-04 07:37:02 [-0400], Austin S. Hemmelgarn wrote: clued enough to have known better. Reassigning bug reports in question from gcc-6 to linux is beyond stupid; Balint is either being deliberately obtuse, or geniunely unable

Re: [PATCH 2/2] kbuild: add -fno-PIE

On 2016-11-04 10:24, Sebastian Andrzej Siewior wrote: On 2016-11-04 07:37:02 [-0400], Austin S. Hemmelgarn wrote: clued enough to have known better. Reassigning bug reports in question from gcc-6 to linux is beyond stupid; Balint is either being deliberately obtuse, or geniunely unable

Re: [PATCH 2/2] kbuild: add -fno-PIE

On 2016-11-03 21:08, Al Viro wrote: On Thu, Nov 03, 2016 at 04:50:55PM -0600, Ben Hutchings wrote: On Wed, 2016-11-02 at 18:20 +0100, Sebastian Andrzej Siewior wrote: Debian started to build the gcc with -fPIE by default so the kernel build ends before it starts properly with:

Re: [PATCH 2/2] kbuild: add -fno-PIE

On 2016-11-03 21:08, Al Viro wrote: On Thu, Nov 03, 2016 at 04:50:55PM -0600, Ben Hutchings wrote: On Wed, 2016-11-02 at 18:20 +0100, Sebastian Andrzej Siewior wrote: Debian started to build the gcc with -fPIE by default so the kernel build ends before it starts properly with:

Re: [RFC] [PATCH] Add a "nolinks" mount option.

On 2016-10-17 09:02, Mattias Nissler wrote: OK, no more feedback thus far. Is there generally any interest in a mount option to avoid path name aliasing resulting in target file confusion? Perhaps a version that only disables symlinks instead of also hard-disabling files hard-linked to multiple

Re: [RFC] [PATCH] Add a "nolinks" mount option.

On 2016-10-17 09:02, Mattias Nissler wrote: OK, no more feedback thus far. Is there generally any interest in a mount option to avoid path name aliasing resulting in target file confusion? Perhaps a version that only disables symlinks instead of also hard-disabling files hard-linked to multiple

Re: md/raid1: Improve another size determination in setup_conf()

On 2016-10-07 06:50, SF Markus Elfring wrote: Linux has tons of issues, fixes for real problems are very welcome. Is a spectrum of software improvements to reconsider there? But coding style bike shedding is just a waste of time. Why do various software developers bother about coding

Re: md/raid1: Improve another size determination in setup_conf()

On 2016-10-07 06:50, SF Markus Elfring wrote: Linux has tons of issues, fixes for real problems are very welcome. Is a spectrum of software improvements to reconsider there? But coding style bike shedding is just a waste of time. Why do various software developers bother about coding

Re: [PATCH V3 00/11] block-throttle: add .high limit

On 2016-10-06 11:05, Paolo Valente wrote: Il giorno 06 ott 2016, alle ore 15:52, Austin S. Hemmelgarn <ahferro...@gmail.com> ha scritto: On 2016-10-06 08:50, Paolo Valente wrote: Il giorno 06 ott 2016, alle ore 13:57, Austin S. Hemmelgarn <ahferro...@gmail.com> ha scritto: O

Re: [PATCH V3 00/11] block-throttle: add .high limit

On 2016-10-06 11:05, Paolo Valente wrote: Il giorno 06 ott 2016, alle ore 15:52, Austin S. Hemmelgarn ha scritto: On 2016-10-06 08:50, Paolo Valente wrote: Il giorno 06 ott 2016, alle ore 13:57, Austin S. Hemmelgarn ha scritto: On 2016-10-06 07:03, Mark Brown wrote: On Thu, Oct 06

Re: [PATCH V3 00/11] block-throttle: add .high limit

On 2016-10-06 08:50, Paolo Valente wrote: Il giorno 06 ott 2016, alle ore 13:57, Austin S. Hemmelgarn <ahferro...@gmail.com> ha scritto: On 2016-10-06 07:03, Mark Brown wrote: On Thu, Oct 06, 2016 at 10:04:41AM +0200, Linus Walleij wrote: On Tue, Oct 4, 2016 at 9:14 PM, Tejun

Re: [PATCH V3 00/11] block-throttle: add .high limit

On 2016-10-06 08:50, Paolo Valente wrote: Il giorno 06 ott 2016, alle ore 13:57, Austin S. Hemmelgarn ha scritto: On 2016-10-06 07:03, Mark Brown wrote: On Thu, Oct 06, 2016 at 10:04:41AM +0200, Linus Walleij wrote: On Tue, Oct 4, 2016 at 9:14 PM, Tejun Heo wrote: I get that bfq can

Re: [PATCH V3 00/11] block-throttle: add .high limit

On 2016-10-06 07:03, Mark Brown wrote: On Thu, Oct 06, 2016 at 10:04:41AM +0200, Linus Walleij wrote: On Tue, Oct 4, 2016 at 9:14 PM, Tejun Heo wrote: I get that bfq can be a good compromise on most desktop workloads and behave reasonably well for some server workloads with

Re: [PATCH V3 00/11] block-throttle: add .high limit

On 2016-10-06 07:03, Mark Brown wrote: On Thu, Oct 06, 2016 at 10:04:41AM +0200, Linus Walleij wrote: On Tue, Oct 4, 2016 at 9:14 PM, Tejun Heo wrote: I get that bfq can be a good compromise on most desktop workloads and behave reasonably well for some server workloads with the slice

Re: TRIM/UNMAP/DISCARD via ATA Passthrough

On 2016-09-17 01:14, James Bottomley wrote: On Fri, 2016-09-16 at 13:06 -0400, Austin S. Hemmelgarn wrote: On 2016-09-16 12:21, James Bottomley wrote: On Fri, 2016-09-16 at 11:53 -0400, Austin S. Hemmelgarn wrote: On 2016-09-16 07:16, Hannes Reinecke wrote: On 09/15/2016 10:52 PM, Jason

Re: TRIM/UNMAP/DISCARD via ATA Passthrough

On 2016-09-17 01:14, James Bottomley wrote: On Fri, 2016-09-16 at 13:06 -0400, Austin S. Hemmelgarn wrote: On 2016-09-16 12:21, James Bottomley wrote: On Fri, 2016-09-16 at 11:53 -0400, Austin S. Hemmelgarn wrote: On 2016-09-16 07:16, Hannes Reinecke wrote: On 09/15/2016 10:52 PM, Jason

Re: TRIM/UNMAP/DISCARD via ATA Passthrough

On 2016-09-16 12:21, James Bottomley wrote: On Fri, 2016-09-16 at 11:53 -0400, Austin S. Hemmelgarn wrote: On 2016-09-16 07:16, Hannes Reinecke wrote: On 09/15/2016 10:52 PM, Jason A. Donenfeld wrote: Hi Martin, On Thu, Sep 15, 2016 at 6:07 PM, Martin K. Petersen But how do they signal

Re: TRIM/UNMAP/DISCARD via ATA Passthrough

On 2016-09-16 12:21, James Bottomley wrote: On Fri, 2016-09-16 at 11:53 -0400, Austin S. Hemmelgarn wrote: On 2016-09-16 07:16, Hannes Reinecke wrote: On 09/15/2016 10:52 PM, Jason A. Donenfeld wrote: Hi Martin, On Thu, Sep 15, 2016 at 6:07 PM, Martin K. Petersen But how do they signal

Re: TRIM/UNMAP/DISCARD via ATA Passthrough

On 2016-09-16 07:16, Hannes Reinecke wrote: On 09/15/2016 10:52 PM, Jason A. Donenfeld wrote: Hi Martin, On Thu, Sep 15, 2016 at 6:07 PM, Martin K. Petersen But how do they signal that ATA passthrough is possible? Is there an ATA Information VPD page? Is REPORT SUPPORTED OPERATION CODES

Re: TRIM/UNMAP/DISCARD via ATA Passthrough

On 2016-09-16 07:16, Hannes Reinecke wrote: On 09/15/2016 10:52 PM, Jason A. Donenfeld wrote: Hi Martin, On Thu, Sep 15, 2016 at 6:07 PM, Martin K. Petersen But how do they signal that ATA passthrough is possible? Is there an ATA Information VPD page? Is REPORT SUPPORTED OPERATION CODES

Re: [PATCH] logfs: remove from tree

On 2016-09-12 02:55, Artem Bityutskiy wrote: On Sun, 2016-09-11 at 15:04 +0200, Christoph Hellwig wrote: Logfs was introduced to the kernel in 2009, and hasn't seen any non drive-by changes since 2012, while having lots of unsolved issues including the complete lack of error handling, with more

Re: [PATCH] logfs: remove from tree

On 2016-09-12 02:55, Artem Bityutskiy wrote: On Sun, 2016-09-11 at 15:04 +0200, Christoph Hellwig wrote: Logfs was introduced to the kernel in 2009, and hasn't seen any non drive-by changes since 2012, while having lots of unsolved issues including the complete lack of error handling, with more

Re: [Documentation] State of CPU controller in cgroup v2

On 2016-09-09 18:57, Tejun Heo wrote: Hello, again. On Mon, Sep 05, 2016 at 10:37:55AM -0700, Andy Lutomirski wrote: * It doesn't bring any practical benefits in terms of capability. Userland can trivially handle the system-root and namespace-roots in a symmetrical manner. Your idea of

Re: [Documentation] State of CPU controller in cgroup v2

On 2016-09-09 18:57, Tejun Heo wrote: Hello, again. On Mon, Sep 05, 2016 at 10:37:55AM -0700, Andy Lutomirski wrote: * It doesn't bring any practical benefits in terms of capability. Userland can trivially handle the system-root and namespace-roots in a symmetrical manner. Your idea of

Re: bcache vs bcachefs

On 2016-09-06 20:55, Kent Overstreet wrote: On Tue, Sep 06, 2016 at 11:46:28AM +0200, Harald Dunkel wrote: Hi folks, I am pretty hesitant replacing the rock-solid ext4 by bcachefs on my servers. Meaning no offense, but surely I would prefer to have ext4 with a thin "SSD caching layer" over a

Re: bcache vs bcachefs

On 2016-09-06 20:55, Kent Overstreet wrote: On Tue, Sep 06, 2016 at 11:46:28AM +0200, Harald Dunkel wrote: Hi folks, I am pretty hesitant replacing the rock-solid ext4 by bcachefs on my servers. Meaning no offense, but surely I would prefer to have ext4 with a thin "SSD caching layer" over a

Re: Who reordered my disks (probably v4.8-rc1 problem)

On 2016-08-13 15:30, Pavel Machek wrote: Hi! It seems that in v4.8-rc0, /dev/sdX got reordered, and now USB devices are probed before SATA drivers. That is pretty anti-social. It broke my boot on my primary machine, and unfortunately due to BIOS problems (keyboard does not work when connected

Re: Who reordered my disks (probably v4.8-rc1 problem)

On 2016-08-13 15:30, Pavel Machek wrote: Hi! It seems that in v4.8-rc0, /dev/sdX got reordered, and now USB devices are probed before SATA drivers. That is pretty anti-social. It broke my boot on my primary machine, and unfortunately due to BIOS problems (keyboard does not work when connected

Re: [PATCH 0002/1285] Replace numeric parameter like 0444 with macro

On 2016-08-02 06:33, Baole Ni wrote: I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can

Re: [PATCH 0002/1285] Replace numeric parameter like 0444 with macro

On 2016-08-02 06:33, Baole Ni wrote: I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can

Re: [PATCH 00/14] Present useful limits to user (v2)

On 2016-07-15 16:54, H. Peter Anvin wrote: On July 15, 2016 6:59:56 AM PDT, Peter Zijlstra wrote: On Fri, Jul 15, 2016 at 01:52:48PM +, Topi Miettinen wrote: On 07/15/16 12:43, Peter Zijlstra wrote: On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:

Re: [PATCH 00/14] Present useful limits to user (v2)

On 2016-07-15 16:54, H. Peter Anvin wrote: On July 15, 2016 6:59:56 AM PDT, Peter Zijlstra wrote: On Fri, Jul 15, 2016 at 01:52:48PM +, Topi Miettinen wrote: On 07/15/16 12:43, Peter Zijlstra wrote: On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote: Hello, There are many

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-22 01:16, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 15:31:07 schrieb Austin S. Hemmelgarn: Hi Austin, Little data, interesting statement for results on 200+ systems including all major CPU arches all showing information leading in the same directions. Let me try

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-22 01:16, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 15:31:07 schrieb Austin S. Hemmelgarn: Hi Austin, Little data, interesting statement for results on 200+ systems including all major CPU arches all showing information leading in the same directions. Let me try

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-21 14:04, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 13:51:15 schrieb Austin S. Hemmelgarn: 6. You have a significant lack of data regarding embedded systems, which is one of the two biggest segments of Linux's market share. You list no results for any pre-ARMv6 systems

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-21 14:04, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 13:51:15 schrieb Austin S. Hemmelgarn: 6. You have a significant lack of data regarding embedded systems, which is one of the two biggest segments of Linux's market share. You list no results for any pre-ARMv6 systems

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-21 09:19, Tomas Mraz wrote: On Út, 2016-06-21 at 09:05 -0400, Austin S. Hemmelgarn wrote: On 2016-06-20 14:32, Stephan Mueller wrote: [1] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf Specific things I notice about this: 1. QEMU systems are reporting higher values than

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-21 09:19, Tomas Mraz wrote: On Út, 2016-06-21 at 09:05 -0400, Austin S. Hemmelgarn wrote: On 2016-06-20 14:32, Stephan Mueller wrote: [1] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf Specific things I notice about this: 1. QEMU systems are reporting higher values than

Re: [PATCH v5 0/7] /dev/random - a new approach

On 2016-06-21 12:28, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 12:03:56 schrieb Austin S. Hemmelgarn: Hi Austin, On 2016-06-21 03:32, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 09:12:07 schrieb Nikos Mavrogiannopoulos: Hi Nikos, On Mon, Jun 20, 2016 at 5:43 PM, Stephan

Re: [PATCH v5 0/7] /dev/random - a new approach

On 2016-06-21 12:28, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 12:03:56 schrieb Austin S. Hemmelgarn: Hi Austin, On 2016-06-21 03:32, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 09:12:07 schrieb Nikos Mavrogiannopoulos: Hi Nikos, On Mon, Jun 20, 2016 at 5:43 PM, Stephan

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-21 13:23, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn: Hi Austin, You have to trust the host for anything, not just for the entropy in timings. This is completely invalid argument unless you can present a method that one guest can

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-21 13:23, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn: Hi Austin, You have to trust the host for anything, not just for the entropy in timings. This is completely invalid argument unless you can present a method that one guest can

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-21 09:20, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 09:05:55 schrieb Austin S. Hemmelgarn: Hi Austin, On 2016-06-20 14:32, Stephan Mueller wrote: Am Montag, 20. Juni 2016, 13:07:32 schrieb Austin S. Hemmelgarn: Hi Austin, On 2016-06-18 12:31, Stephan Mueller wrote: Am

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-21 09:20, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 09:05:55 schrieb Austin S. Hemmelgarn: Hi Austin, On 2016-06-20 14:32, Stephan Mueller wrote: Am Montag, 20. Juni 2016, 13:07:32 schrieb Austin S. Hemmelgarn: Hi Austin, On 2016-06-18 12:31, Stephan Mueller wrote: Am

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-21 09:42, Pavel Machek wrote: Hi! 6. You have a significant lack of data regarding embedded systems, which is one of the two biggest segments of Linux's market share. You list no results for any pre-ARMv6 systems (Linux still runs on and is regularly used on ARMv4 CPU's, and it's

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-21 09:42, Pavel Machek wrote: Hi! 6. You have a significant lack of data regarding embedded systems, which is one of the two biggest segments of Linux's market share. You list no results for any pre-ARMv6 systems (Linux still runs on and is regularly used on ARMv4 CPU's, and it's

  1   2   3   4   5   6   7   >