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
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:
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':
> + {
> +
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':
> + {
> +
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
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
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
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
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
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
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
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.
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
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;
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.
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
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
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
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
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
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
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
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,
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.
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
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
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.
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.
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
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
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
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
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.
--
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'
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
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.
36 matches
Mail list logo