On Sat, Oct 19, 2019 at 12:10 AM Dave Hansen wrote:
>
> On 10/18/19 1:11 AM, Suleiman Souhlal wrote:
> > Another issue we ran into, that I think might also apply to this patch
> > series, is that because kernel memory can't be allocated on persistent
> > memory, it's
On Fri, Oct 18, 2019 at 1:32 AM Dave Hansen wrote:
>
> On 10/17/19 9:01 AM, Suleiman Souhlal wrote:
> > One problem that came up is that if you get into direct reclaim,
> > because persistent memory can have pretty low write throughput, you
> > can end up stalling user
On Thu, Oct 17, 2019 at 7:14 AM Dave Hansen wrote:
>
> We're starting to see systems with more and more kinds of memory such
> as Intel's implementation of persistent memory.
>
> Let's say you have a system with some DRAM and some persistent memory.
> Today, once DRAM fills up, reclaim will start
On Thu, Oct 10, 2019 at 7:55 PM Paolo Bonzini wrote:
>
> On 10/10/19 09:30, Suleiman Souhlal wrote:
> > +kvm_hostclock_enable(struct clocksource *cs)
> > +{
> > + pv_timekeeper_enabled = 1;
> > +
> > + old_vclock_m
On Thu, Oct 10, 2019 at 7:39 PM Roman Kagan wrote:
>
> I wonder how feasible it is to map the host's vdso into the guest and
> thus make the guest use the *same* (as opposed to "synchronized") clock
> as the host's userspace? Another benefit is that it's essentially an
> ABI so is not changed as
would be highly appreciated.
Changes in v2:
- Move out of kvmclock and into its own clocksource and file.
- Remove timekeeping.c #ifdefs.
- Fix i386 build.
Suleiman Souhlal (2):
kvm: Mechanism to copy host timekeeping parameters into guest.
x86/kvmclock: Introduce kvm-hostclock clocksource
This is used to synchronize time between host and guest.
The guest can request the (guest) physical address it wants the
data in through the MSR_KVM_TIMEKEEPER_EN MSR.
It currently assumes the host timekeeper is "tsc".
Signed-off-by: Suleiman Souhlal
---
arch/x86/include/asm/
When kvm-hostclock is selected, and the host supports it, update our
timekeeping parameters to be the same as the host.
This lets us have our time synchronized with the host's,
even in the presence of host NTP or suspend.
Signed-off-by: Suleiman Souhlal
---
arch/x86/Kconfig
On Wed, Oct 2, 2019 at 11:09 AM Roman Gushchin wrote:
>
> On Tue, Oct 01, 2019 at 05:12:02PM +0200, Michal Koutný wrote:
> > On Thu, Sep 05, 2019 at 02:45:44PM -0700, Roman Gushchin
> > wrote:
> > > Roman Gushchin (14):
> > > [...]
> > > mm: memcg/slab: use one set of kmem_caches for all
On Fri, Sep 20, 2019 at 10:33 PM Vitaly Kuznetsov wrote:
>
> Suleiman Souhlal writes:
>
> > When CONFIG_KVMCLOCK_HOST_TIMEKEEPING is enabled, and the host
> > supports it, update our timekeeping parameters to be the same as
> > the host. This lets us have our time s
On Fri, Sep 20, 2019 at 7:23 PM Thomas Gleixner wrote:
>
> On Fri, 20 Sep 2019, Paolo Bonzini wrote:
>
> > On 20/09/19 08:27, Suleiman Souhlal wrote:
> > > To do that, I am changing kvmclock to request to the host to copy
> > > its timekeeping parameters
into the
guest.
It currently assumes the host timekeeper is "tsc".
Signed-off-by: Suleiman Souhlal
---
arch/x86/include/asm/kvm_host.h | 3 +
arch/x86/include/asm/pvclock-abi.h | 27 ++
arch/x86/include/uapi/asm/kvm_para.h | 1 +
arch/x86/kvm/x86.c
would be highly appreciated.
Suleiman Souhlal (2):
kvm: Mechanism to copy host timekeeping parameters into guest.
x86/kvmclock: Use host timekeeping.
arch/x86/Kconfig | 9 ++
arch/x86/include/asm/kvm_host.h | 3 +
arch/x86/include/asm/kvmclock.h | 2 +
arch
.
When enabled, syscalls that can change time, such as settimeofday(2)
or adj_timex(2) are disabled in the guest.
Signed-off-by: Suleiman Souhlal
---
arch/x86/Kconfig| 9 +++
arch/x86/include/asm/kvmclock.h | 2 +
arch/x86/kernel/kvmclock.c | 127
On Fri, Sep 20, 2019 at 1:22 AM Roman Gushchin wrote:
>
> On Thu, Sep 19, 2019 at 10:39:18PM +0900, Suleiman Souhlal wrote:
> > On Fri, Sep 6, 2019 at 6:57 AM Roman Gushchin wrote:
> > > The patchset has been tested on a number of different workloads in our
> >
On Fri, Sep 6, 2019 at 6:57 AM Roman Gushchin wrote:
> The patchset has been tested on a number of different workloads in our
> production. In all cases, it saved hefty amounts of memory:
> 1) web frontend, 650-700 Mb, ~42% of slab memory
> 2) database cache, 750-800 Mb, ~35% of slab memory
> 3)
On Mon, Sep 15, 2014 at 3:44 AM, Vladimir Davydov
wrote:
> Hi,
>
> I'd like to discuss downsides of the kmem accounting part of the memory
> cgroup controller and a possible way to fix them. I'd really appreciate
> if you could share your thoughts on it.
>
> The idea lying behind the kmem
On Mon, Sep 15, 2014 at 3:44 AM, Vladimir Davydov
vdavy...@parallels.com wrote:
Hi,
I'd like to discuss downsides of the kmem accounting part of the memory
cgroup controller and a possible way to fix them. I'd really appreciate
if you could share your thoughts on it.
The idea lying behind
Hello,
On Apr 10, 2013, at 11:18 , Seth Jennings wrote:
> +/* invalidates all pages for the given swap type */
> +static void zswap_frontswap_invalidate_area(unsigned type)
> +{
> + struct zswap_tree *tree = zswap_trees[type];
> + struct rb_node *node;
> + struct zswap_entry *entry;
Hello,
On Apr 10, 2013, at 11:18 , Seth Jennings wrote:
+/* invalidates all pages for the given swap type */
+static void zswap_frontswap_invalidate_area(unsigned type)
+{
+ struct zswap_tree *tree = zswap_trees[type];
+ struct rb_node *node;
+ struct zswap_entry *entry;
+
+
On Oct 12, 2007, at 7:58 AM, Peter Zijlstra wrote:
On Fri, 2007-10-12 at 07:53 -0700, Arjan van de Ven wrote:
On Fri, 12 Oct 2007 12:50:22 +0200
The pages will still be read-only due to dirty tracking, so the
first write will still do page_mkwrite().
Which can SIGBUS, no?
Sure, but that
On Jul 26, 2007, at 11:33 PM, Peter Zijlstra wrote:
On Thu, 2007-07-26 at 17:23 -0700, Andrew Morton wrote:
On Thu, 26 Jul 2007 16:52:44 -0700 Suleiman Souhlal
<[EMAIL PROTECTED]> wrote:
make_pages_present() is dirtying mlocked pages if the VMA is
writable, even
though it sho
On Jul 26, 2007, at 11:33 PM, Peter Zijlstra wrote:
On Thu, 2007-07-26 at 17:23 -0700, Andrew Morton wrote:
On Thu, 26 Jul 2007 16:52:44 -0700 Suleiman Souhlal
[EMAIL PROTECTED] wrote:
make_pages_present() is dirtying mlocked pages if the VMA is
writable, even
though it shouldn't
On Oct 12, 2007, at 7:58 AM, Peter Zijlstra wrote:
On Fri, 2007-10-12 at 07:53 -0700, Arjan van de Ven wrote:
On Fri, 12 Oct 2007 12:50:22 +0200
The pages will still be read-only due to dirty tracking, so the
first write will still do page_mkwrite().
Which can SIGBUS, no?
Sure, but that
to just not simulate a write fault.
Signed-off-by: Suleiman Souhlal <[EMAIL PROTECTED]>
---
mm/memory.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index f64cbf9..f43c9e8 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2664,18 +2
to just not simulate a write fault.
Signed-off-by: Suleiman Souhlal [EMAIL PROTECTED]
---
mm/memory.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index f64cbf9..f43c9e8 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2664,18 +2664,17 @@ #endif
On Fri, April 6, 2007 12:22 pm, Sergei Shtylyov wrote:
> Hello.
>
>
> Suleiman Souhlal wrote:
>
>
>> It is possible for the timer expiry function to run even though the
>> request has already been handled: ide_timer_expiry() only checks that the
>> handler is
incremented at every interrupt, and check in ide_timer_expiry() that
we have not already handled a new interrupt before running the expiry
function.
Signed-off-by: Suleiman Souhlal <[EMAIL PROTECTED]>
---
drivers/ide/ide-io.c |6 +-
drivers/ide/ide-iops.c |2 ++
include/linux
incremented at every interrupt, and check in ide_timer_expiry() that
we have not already handled a new interrupt before running the expiry
function.
Signed-off-by: Suleiman Souhlal [EMAIL PROTECTED]
---
drivers/ide/ide-io.c |6 +-
drivers/ide/ide-iops.c |2 ++
include/linux/ide.h|2
On Fri, April 6, 2007 12:22 pm, Sergei Shtylyov wrote:
Hello.
Suleiman Souhlal wrote:
It is possible for the timer expiry function to run even though the
request has already been handled: ide_timer_expiry() only checks that the
handler is not NULL, but it is possible that we have handled
On Mar 8, 2007, at 12:34 PM, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Thursday 08 March 2007, Suleiman Souhlal wrote:
On Mar 7, 2007, at 1:16 PM, Bartlomiej Zolnierkiewicz wrote:
Hi,
(sorry for the long delay)
On Wednesday 21 February 2007, Suleiman Souhlal wrote:
IDE error recovery
On Mar 7, 2007, at 1:16 PM, Bartlomiej Zolnierkiewicz wrote:
Hi,
(sorry for the long delay)
On Wednesday 21 February 2007, Suleiman Souhlal wrote:
IDE error recovery is using WIN_IDLEIMMEDIATE which was only valid
for
IDE V1 and IDE V2. Modern drives will not be able to recover using
On Mar 7, 2007, at 1:16 PM, Bartlomiej Zolnierkiewicz wrote:
Hi,
(sorry for the long delay)
On Wednesday 21 February 2007, Suleiman Souhlal wrote:
IDE error recovery is using WIN_IDLEIMMEDIATE which was only valid
for
IDE V1 and IDE V2. Modern drives will not be able to recover using
On Mar 8, 2007, at 12:34 PM, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Thursday 08 March 2007, Suleiman Souhlal wrote:
On Mar 7, 2007, at 1:16 PM, Bartlomiej Zolnierkiewicz wrote:
Hi,
(sorry for the long delay)
On Wednesday 21 February 2007, Suleiman Souhlal wrote:
IDE error recovery
On Feb 20, 2007, at 5:44 PM, Bartlomiej Zolnierkiewicz wrote:
On Wednesday 21 February 2007 02:19, Suleiman Souhlal wrote:
It can be changed via /proc/ide/hd?/settings.
Why do we need to change IDE DMA timeout dynamically?
I've used it to test error recovery (for example).
BTW /proc
ile there, remove some commented-out code.
Signed-off-by: Suleiman Souhlal <[EMAIL PROTECTED]>
---
drivers/ide/ide-iops.c | 35 ---
1 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/drivers/ide/ide-iops.c b/drivers/ide/ide-iops.c
inde
IDE error recovery is using WIN_IDLEIMMEDIATE which was only valid for
IDE V1 and IDE V2. Modern drives will not be able to recover using
this error handling. The correct thing to do is issue a SRST followed
by a SET_FEATURES.
Signed-off-by: Suleiman Souhlal <[EMAIL PROTECTED]>
---
d
It can be changed via /proc/ide/hd?/settings.
Signed-off-by: Ed Falk <[EMAIL PROTECTED]>
---
drivers/ide/ide-dma.c |3 ++-
drivers/ide/ide.c |2 ++
include/linux/ide.h |3 +++
3 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/ide/ide-dma.c
It can be changed via /proc/ide/hd?/settings.
Signed-off-by: Ed Falk [EMAIL PROTECTED]
---
drivers/ide/ide-dma.c |3 ++-
drivers/ide/ide.c |2 ++
include/linux/ide.h |3 +++
3 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/ide/ide-dma.c
IDE error recovery is using WIN_IDLEIMMEDIATE which was only valid for
IDE V1 and IDE V2. Modern drives will not be able to recover using
this error handling. The correct thing to do is issue a SRST followed
by a SET_FEATURES.
Signed-off-by: Suleiman Souhlal [EMAIL PROTECTED]
---
drivers/ide
there, remove some commented-out code.
Signed-off-by: Suleiman Souhlal [EMAIL PROTECTED]
---
drivers/ide/ide-iops.c | 35 ---
1 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/drivers/ide/ide-iops.c b/drivers/ide/ide-iops.c
index c67b3b1..35ab3af
On Feb 20, 2007, at 5:44 PM, Bartlomiej Zolnierkiewicz wrote:
On Wednesday 21 February 2007 02:19, Suleiman Souhlal wrote:
It can be changed via /proc/ide/hd?/settings.
Why do we need to change IDE DMA timeout dynamically?
I've used it to test error recovery (for example).
BTW /proc
Suleiman Souhlal wrote:
Andrew Morton wrote:
On Wed, 13 Dec 2006 00:45:50 -0800
Suleiman Souhlal <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
From: Andrew Morton <[EMAIL PROTECTED]>
Accounting writes is fairly simple: whenever a process flips a page
from clean
to dirt
Andrew Morton wrote:
On Wed, 13 Dec 2006 00:45:50 -0800
Suleiman Souhlal <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
From: Andrew Morton <[EMAIL PROTECTED]>
Accounting writes is fairly simple: whenever a process flips a page from clean
to dirty, we accuse it of h
[EMAIL PROTECTED] wrote:
From: Andrew Morton <[EMAIL PROTECTED]>
Accounting writes is fairly simple: whenever a process flips a page from clean
to dirty, we accuse it of having caused a write to underlying storage of
PAGE_CACHE_SIZE bytes.
On architectures where dirtying a page doesn't cause
[EMAIL PROTECTED] wrote:
From: Andrew Morton [EMAIL PROTECTED]
Accounting writes is fairly simple: whenever a process flips a page from clean
to dirty, we accuse it of having caused a write to underlying storage of
PAGE_CACHE_SIZE bytes.
On architectures where dirtying a page doesn't cause a
Andrew Morton wrote:
On Wed, 13 Dec 2006 00:45:50 -0800
Suleiman Souhlal [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
From: Andrew Morton [EMAIL PROTECTED]
Accounting writes is fairly simple: whenever a process flips a page from clean
to dirty, we accuse it of having caused a write
Suleiman Souhlal wrote:
Andrew Morton wrote:
On Wed, 13 Dec 2006 00:45:50 -0800
Suleiman Souhlal [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
From: Andrew Morton [EMAIL PROTECTED]
Accounting writes is fairly simple: whenever a process flips a page
from clean
to dirty, we accuse
48 matches
Mail list logo
