Re: [PATCH][v6] tools/power turbostat: if --iterations, print for specific count of iterations

2018-04-27 Thread Bityutskiy, Artem
On Thu, 2018-04-26 at 08:41 +0800, Chen Yu wrote: > There's a use case during test to only print specific round of iterations > if --iterations is specified, for example, with this patch applied: > > turbostat -i 5 -r 4 > will capture 4 samples with 5 seconds interval. > > Cc: Len Brown

Re: [PATCH][v6] tools/power turbostat: if --iterations, print for specific count of iterations

2018-04-27 Thread Bityutskiy, Artem
On Thu, 2018-04-26 at 08:41 +0800, Chen Yu wrote: > There's a use case during test to only print specific round of iterations > if --iterations is specified, for example, with this patch applied: > > turbostat -i 5 -r 4 > will capture 4 samples with 5 seconds interval. > > Cc: Len Brown > Cc:

Re: [PATCH][RFC] tools/power turbostat: if --max_loop, print for specific time of loops

2018-04-10 Thread Bityutskiy, Artem
On Tue, 2018-04-10 at 18:18 +0800, Yu Chen wrote: > @@ -5076,6 +5084,15 @@ void cmdline(int argc, char **argv) > print_version(); > exit(0); > break; > + case 'x': > + { > +

Re: [PATCH][RFC] tools/power turbostat: if --max_loop, print for specific time of loops

2018-04-10 Thread Bityutskiy, Artem
On Tue, 2018-04-10 at 18:18 +0800, Yu Chen wrote: > @@ -5076,6 +5084,15 @@ void cmdline(int argc, char **argv) > print_version(); > exit(0); > break; > + case 'x': > + { > +

regression: SCSI/SATA failure

2018-02-22 Thread Bityutskiy, Artem
Hi Christoph, one of our test box Skylake servers does not boot with v4.16-rcX. Bisection lead us to this commit: 84676c1f21e8 genirq/affinity: assign vectors to all possible CPUs Reverting this single commit fixes the problem. The server is a Dell R640 machine with the latest Dell BIOS. It

regression: SCSI/SATA failure

2018-02-22 Thread Bityutskiy, Artem
Hi Christoph, one of our test box Skylake servers does not boot with v4.16-rcX. Bisection lead us to this commit: 84676c1f21e8 genirq/affinity: assign vectors to all possible CPUs Reverting this single commit fixes the problem. The server is a Dell R640 machine with the latest Dell BIOS. It

Re: sync issues in 4.3-rc1?

2015-09-18 Thread Bityutskiy, Artem
On Fri, 2015-09-18 at 19:46 +0300, Artem Bityutskiy wrote: > Hi, > > I observe a problem in 4.3-rc1 which looks like there are issues with > sync - it does not really sync all. The FS is ext4, a plain partition mounted (no lvm, no encryption, etc). The disk is SATA SSD, but I believe I observed

Re: sync issues in 4.3-rc1?

2015-09-18 Thread Bityutskiy, Artem
On Fri, 2015-09-18 at 19:46 +0300, Artem Bityutskiy wrote: > Hi, > > I observe a problem in 4.3-rc1 which looks like there are issues with > sync - it does not really sync all. The FS is ext4, a plain partition mounted (no lvm, no encryption, etc). The disk is SATA SSD, but I believe I observed

Re: autoNUMA web workload regression

2015-05-06 Thread Bityutskiy, Artem
On Wed, 2015-05-06 at 13:35 +0300, Artem Bityutskiy wrote: > If I take 4.1-rc1 and revert this patch, I observe 300% or more average > response time improvement comparing to vanilla 3.17. Sorry, I meant vanilla 4.1-rc1 here, not 3.17. -- Best Regards, Artem Bityutskiy

Re: autoNUMA web workload regression

2015-05-06 Thread Bityutskiy, Artem
On Wed, 2015-05-06 at 13:35 +0300, Artem Bityutskiy wrote: If I take 4.1-rc1 and revert this patch, I observe 300% or more average response time improvement comparing to vanilla 3.17. Sorry, I meant vanilla 4.1-rc1 here, not 3.17. -- Best Regards, Artem Bityutskiy

Re: [PATCH 3/4] UBI: Fastmap: Care about the protection queue

2014-10-13 Thread Bityutskiy, Artem
On Mon, 2014-10-13 at 18:23 +0300, Artem Bityutskiy wrote: > > The interface would work but some work in wl.c is needed. > > For example if I want to find out in which state PEB 1 is wl.c would have to > > look int free free, used free, protection queue, etc.. to tell me the > > state. This is

Re: [PATCH 3/4] UBI: Fastmap: Care about the protection queue

2014-10-13 Thread Bityutskiy, Artem
On Mon, 2014-10-13 at 18:23 +0300, Artem Bityutskiy wrote: The interface would work but some work in wl.c is needed. For example if I want to find out in which state PEB 1 is wl.c would have to look int free free, used free, protection queue, etc.. to tell me the state. This is slow.

Re: [PATCH 1/4] UBI: Ensure that all fastmap work is done upon WL shutdown

2014-09-30 Thread Bityutskiy, Artem
On Tue, 2014-09-30 at 08:58 +0200, Richard Weinberger wrote: > Am 30.09.2014 08:26, schrieb Artem Bityutskiy: > > On Tue, 2014-09-30 at 00:20 +0200, Richard Weinberger wrote: > >> ...otherwise the deferred work might run after datastructures > >> got freed and corrupt memory. > > > > How can this

Re: [PATCH 4/4] UBI: Fastmap: Ensure that only one fastmap work is scheduled

2014-09-30 Thread Bityutskiy, Artem
On Tue, 2014-09-30 at 08:59 +0200, Richard Weinberger wrote: > Am 30.09.2014 08:45, schrieb Bityutskiy, Artem: > > On Tue, 2014-09-30 at 00:20 +0200, Richard Weinberger wrote: > >> + spin_lock(>wl_lock); > >> + ubi->fm_work_scheduled = 0;

Re: [PATCH 4/4] UBI: Fastmap: Ensure that only one fastmap work is scheduled

2014-09-30 Thread Bityutskiy, Artem
On Tue, 2014-09-30 at 00:20 +0200, Richard Weinberger wrote: > + spin_lock(>wl_lock); > + ubi->fm_work_scheduled = 0; > + spin_unlock(>wl_lock); Andrew Morton once said me that if I am protecting an integer change like this with a spinlock, I have a problem in my locking design.

Re: [RFC] UBI bitrot checking

2014-09-30 Thread Bityutskiy, Artem
On Wed, 2014-09-24 at 00:06 +0200, Richard Weinberger wrote: > This is a very initial draft for one possibility of bitrot checking in UBI. > The basic idea is to have a worker function which reads a complete PEB and > schedules scrubbing if bit flips are detected. > Currently this check is

Re: Two lame typo fixes

2014-09-30 Thread Bityutskiy, Artem
On Tue, 2014-09-30 at 00:24 +0200, Richard Weinberger wrote: > On Tue, Sep 16, 2014 at 3:30 PM, Richard Weinberger wrote: > > ...found them while browsing. > > > > Thanks, > > //richard > > > > [PATCH 1/2] UBI: Fix trivial typo in __schedule_ubi_work > > [PATCH 2/2] UBIFS: Fix trivial typo in

Re: Two lame typo fixes

2014-09-30 Thread Bityutskiy, Artem
On Tue, 2014-09-30 at 00:24 +0200, Richard Weinberger wrote: On Tue, Sep 16, 2014 at 3:30 PM, Richard Weinberger rich...@nod.at wrote: ...found them while browsing. Thanks, //richard [PATCH 1/2] UBI: Fix trivial typo in __schedule_ubi_work [PATCH 2/2] UBIFS: Fix trivial typo in

Re: [RFC] UBI bitrot checking

2014-09-30 Thread Bityutskiy, Artem
On Wed, 2014-09-24 at 00:06 +0200, Richard Weinberger wrote: This is a very initial draft for one possibility of bitrot checking in UBI. The basic idea is to have a worker function which reads a complete PEB and schedules scrubbing if bit flips are detected. Currently this check is triggered

Re: [PATCH 4/4] UBI: Fastmap: Ensure that only one fastmap work is scheduled

2014-09-30 Thread Bityutskiy, Artem
On Tue, 2014-09-30 at 00:20 +0200, Richard Weinberger wrote: + spin_lock(ubi-wl_lock); + ubi-fm_work_scheduled = 0; + spin_unlock(ubi-wl_lock); Andrew Morton once said me that if I am protecting an integer change like this with a spinlock, I have a problem in my locking

Re: [PATCH 4/4] UBI: Fastmap: Ensure that only one fastmap work is scheduled

2014-09-30 Thread Bityutskiy, Artem
On Tue, 2014-09-30 at 08:59 +0200, Richard Weinberger wrote: Am 30.09.2014 08:45, schrieb Bityutskiy, Artem: On Tue, 2014-09-30 at 00:20 +0200, Richard Weinberger wrote: + spin_lock(ubi-wl_lock); + ubi-fm_work_scheduled = 0; + spin_unlock(ubi-wl_lock); Andrew Morton

Re: [PATCH 1/4] UBI: Ensure that all fastmap work is done upon WL shutdown

2014-09-30 Thread Bityutskiy, Artem
On Tue, 2014-09-30 at 08:58 +0200, Richard Weinberger wrote: Am 30.09.2014 08:26, schrieb Artem Bityutskiy: On Tue, 2014-09-30 at 00:20 +0200, Richard Weinberger wrote: ...otherwise the deferred work might run after datastructures got freed and corrupt memory. How can this happend? The

Re: [PATCH] sysctl: Add a feature to drop caches selectively

2014-06-27 Thread Bityutskiy, Artem
On Fri, 2014-06-27 at 12:08 +0300, Artem Bityutskiy wrote: > To make 100% sure you'd not only need to drop VFS-level caches but also > file-system-level caches. Indeed, file-systems have their own rather Sorry, I wanted to say "rather complex" here > buffers for different indexing data-structures,

Re: [PATCH] sysctl: Add a feature to drop caches selectively

2014-06-27 Thread Bityutskiy, Artem
On Fri, 2014-06-27 at 12:08 +0300, Artem Bityutskiy wrote: To make 100% sure you'd not only need to drop VFS-level caches but also file-system-level caches. Indeed, file-systems have their own rather Sorry, I wanted to say rather complex here buffers for different indexing data-structures, etc.

Re: [RFC/PATCH] mtd: ubi: Free peb's synchronously for fastmap

2014-04-08 Thread Bityutskiy, Artem
On Tue, 2014-04-08 at 16:42 +0300, Artem Bityutskiy wrote: > On Tue, 2014-04-01 at 11:01 +0300, Tanya Brokhman wrote: > > At first mount it's possible that there are not enough free PEBs since > > there are PEB's pending to be erased. In such scenario, fm_pool (which is > > the pool from which

Re: [RFC/PATCH] mtd: ubi: Free peb's synchronously for fastmap

2014-04-08 Thread Bityutskiy, Artem
On Tue, 2014-04-08 at 16:42 +0300, Artem Bityutskiy wrote: On Tue, 2014-04-01 at 11:01 +0300, Tanya Brokhman wrote: At first mount it's possible that there are not enough free PEBs since there are PEB's pending to be erased. In such scenario, fm_pool (which is the pool from which user

please, remove UBI tree from linux-next

2014-01-09 Thread Bityutskiy, Artem
Hi Stephen, could you please remove the UBI git tree from linux-next? git://git.infradead.org/linux-ubi I will use the UBIFS git tree for both UBI and UBIFS patches from now on. The traffic became so low that it does not make sense to keep 2 separate trees for these very related subsystems.

please, remove UBI tree from linux-next

2014-01-09 Thread Bityutskiy, Artem
Hi Stephen, could you please remove the UBI git tree from linux-next? git://git.infradead.org/linux-ubi I will use the UBIFS git tree for both UBI and UBIFS patches from now on. The traffic became so low that it does not make sense to keep 2 separate trees for these very related subsystems.

[GIT PULL] UBI changes for 3.11-rc1

2013-07-05 Thread Bityutskiy, Artem
Hellow Linus! The following changes since commit f722406faae2d073cc1d01063d1123c35425939e: Linux 3.10-rc1 (2013-05-11 17:14:08 -0700) are available in the git repository at: git://git.infradead.org/linux-ubi.git tags/upstream-3.11-rc1 for you to fetch changes up to

[GIT PULL] UBI changes for 3.11-rc1

2013-07-05 Thread Bityutskiy, Artem
Hellow Linus! The following changes since commit f722406faae2d073cc1d01063d1123c35425939e: Linux 3.10-rc1 (2013-05-11 17:14:08 -0700) are available in the git repository at: git://git.infradead.org/linux-ubi.git tags/upstream-3.11-rc1 for you to fetch changes up to

Re: [PATCH] x86/PCI: setup data may be in highmem

2013-06-08 Thread Bityutskiy, Artem
On Sat, 2013-06-08 at 14:15 +0300, Artem Bityutskiy wrote: > On Wed, 2013-05-22 at 10:43 +0100, Matt Fleming wrote: > > From: Matt Fleming > > > > pcibios_add_device() assumes that the physical addresses stored in > > setup_data are accessible via the direct kernel mapping, and that > > calling

Re: [PATCH] x86/PCI: setup data may be in highmem

2013-06-08 Thread Bityutskiy, Artem
On Sat, 2013-06-08 at 14:15 +0300, Artem Bityutskiy wrote: On Wed, 2013-05-22 at 10:43 +0100, Matt Fleming wrote: From: Matt Fleming matt.flem...@intel.com pcibios_add_device() assumes that the physical addresses stored in setup_data are accessible via the direct kernel mapping, and that

Re: [PATCH] of: mtd: nuke useless const qualifier

2012-07-10 Thread Bityutskiy, Artem
On Tue, 2012-07-10 at 10:35 -0500, Rob Herring wrote: > > Remove also the unnecessary "extern" qualifier to be consistent with other > > declarations in this file. > > > > Signed-off-by: Artem Bityutskiy > > --- > > Applied. Next time please don't PGP sign patches. Thanks. Sure, I'll try. --

[PATCH] of: mtd: nuke useless const qualifier

2012-07-10 Thread Bityutskiy, Artem
From: Artem Bityutskiy This patch does the following: -const int of_get_nand_ecc_mode(struct device_node *np) +int of_get_nand_ecc_mode(struct device_node *np) because: 1. it is probably just a typo? 2. it causes warnings like this when people assing the returned value to an 'int'

[PATCH] of: mtd: nuke useless const qualifier

2012-07-10 Thread Bityutskiy, Artem
From: Artem Bityutskiy artem.bityuts...@linux.intel.com This patch does the following: -const int of_get_nand_ecc_mode(struct device_node *np) +int of_get_nand_ecc_mode(struct device_node *np) because: 1. it is probably just a typo? 2. it causes warnings like this when people assing the

Re: [PATCH] of: mtd: nuke useless const qualifier

2012-07-10 Thread Bityutskiy, Artem
On Tue, 2012-07-10 at 10:35 -0500, Rob Herring wrote: Remove also the unnecessary extern qualifier to be consistent with other declarations in this file. Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com --- Applied. Next time please don't PGP sign patches. Thanks.