>
> Hi Linus,
>
> When the merge window opens, please pull the RCU changes for v6.16:
>
> The following changes since commit 0af2f6be1b4281385b618cb86ad946eded089ac8:
>
> Linux 6.15-rc1 (2025-04-06 13:11:33 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linu
>
> On 5/9/2025 3:07 PM, Joel Fernandes wrote:
> >
> >
> > On 5/7/2025 7:26 AM, Zqiang wrote:
> >> In the preparation stage of CPU online, if the corresponding
> >> the rdp's->nocb_cb_kthread does not exist, will be created,
> >> there is a situation where the rdp's rcuop kthreads creation fails,
>
>
> On Wed, May 07, 2025 at 07:26:05PM +0800, Zqiang wrote:
> > In the preparation stage of CPU online, if the corresponding
> > the rdp's->nocb_cb_kthread does not exist, will be created,
> > there is a situation where the rdp's rcuop kthreads creation fails,
> > and then de-offload this CPU's rdp
>
> On Thu, May 8, 2025 at 12:25 AM Frederic Weisbecker
> wrote:
> >
> > Le Wed, May 07, 2025 at 07:26:04PM +0800, Zqiang a écrit :
> > > For built with CONFIG_PROVE_RCU=y and CONFIG_PREEMPT_RT=y kernels,
> > > Disable BH does not change the SOFTIRQ corresponding bits in
> > > preempt_count(), bu
On Thu, May 8, 2025 at 12:25 AM Frederic Weisbecker wrote:
>
> Le Wed, May 07, 2025 at 07:26:04PM +0800, Zqiang a écrit :
> > For built with CONFIG_PROVE_RCU=y and CONFIG_PREEMPT_RT=y kernels,
> > Disable BH does not change the SOFTIRQ corresponding bits in
> > preempt_count(), but change current-
>
>
>
> On 4/30/2025 12:14 PM, Joel Fernandes wrote:
> >
> >
> > On 4/30/2025 10:57 AM, Z qiang wrote:
> >>>
> >>>
> >>>
> >>> On 4/28/2025 6:59 AM, Z qiang wrote:
> >>>>>
> >>&
>
>
>
> On 4/28/2025 6:59 AM, Z qiang wrote:
> >>
> >> Le Mon, Apr 28, 2025 at 05:54:03PM +0800, Zqiang a écrit :
> >>> For Preempt-RT kernel, when enable CONFIG_PROVE_RCU Kconfig,
> >>> disable local bh in rcuc kthreads will not affect preem
>
> >
> > Le Mon, Apr 28, 2025 at 05:54:03PM +0800, Zqiang a écrit :
> > > For Preempt-RT kernel, when enable CONFIG_PROVE_RCU Kconfig,
> > > disable local bh in rcuc kthreads will not affect preempt_count(),
> > > this resulted in the following splat:
> > >
> > > WARNING: suspicious RCU usage
> >
>
> Le Mon, Apr 28, 2025 at 05:54:03PM +0800, Zqiang a écrit :
> > For Preempt-RT kernel, when enable CONFIG_PROVE_RCU Kconfig,
> > disable local bh in rcuc kthreads will not affect preempt_count(),
> > this resulted in the following splat:
> >
> > WARNING: suspicious RCU usage
> > kernel/rcu/tree_
>
> This commit adds a new rcutorture.n_up_down kernel boot parameter
> that specifies the number of outstanding SRCU up/down readers, which
> begin in kthread context and end in an hrtimer handler. There is a new
> kthread ("rcu_torture_updown") that scans an per-reader array looking
> for elemen
>
> On Sat, Dec 14, 2024 at 09:53:13PM +0100, Greg Kroah-Hartman wrote:
> > I'm announcing the release of the 6.1.120 kernel.
> >
> > All users of the 6.1 kernel series must upgrade.
> >
> > The updated 6.1.y git tree can be found at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/l
>
> Le Mon, Oct 21, 2024 at 07:01:02PM +0800, Z qiang a écrit :
> > > For the non-nocb cpus set during boot, the corresponding
> > > rcuop kthread, we should park directly, otherwise
> > > WARN_ON_ONCE(!rcu_rdp_is_offloaded(rdp)) will be triggered.
>
> Ah b
>
> >
> > Le Sun, Oct 20, 2024 at 08:51:19PM +0800, Zqiang a écrit :
> > > Currently, running rcutorture test with torture_type=rcu fwd_progress=8
> > > n_barrier_cbs=8 nocbs_nthreads=8 nocbs_toggle=100 onoff_interval=60
> > > test_boost=2, will trigger the following warning:
> > >
> > > WARNING: C
>
> Le Sun, Oct 20, 2024 at 08:51:19PM +0800, Zqiang a écrit :
> > Currently, running rcutorture test with torture_type=rcu fwd_progress=8
> > n_barrier_cbs=8 nocbs_nthreads=8 nocbs_toggle=100 onoff_interval=60
> > test_boost=2, will trigger the following warning:
> >
> > WARNING: CPU: 19 PID: 100
On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote:
> After v5.10 was officially declared an LTS kernel, I had a look around
> the Arm platforms that look like they have not seen any patches from
> their maintainers or users that are actually running the hardware for
> at least five year
ATN:PLEASE/ I AM Mr Mohammad Z. Raqab
Before I introduce myself, I wish to inform you that this letter is
not a hoax mail and I urge you to treat it serious. This letter must ,
come to you as a big surprise, but I believe it is only a day that
people meet and become great friends and business
On Mon, 2019-10-07 at 10:27 -0700, Alexander Duyck wrote:
> From: Alexander Duyck
>
> This patch is meant to address possible race conditions that can exist
> between network configuration and power management. A similar issue was
> fixed for igb in commit 9474933caf21 ("igb: close/suspend race i
On Mon, 2019-10-07 at 10:02 -0700, Alexander Duyck wrote:
> On Mon, Oct 7, 2019 at 8:51 AM David Z. Dai wrote:
> >
>
>
>
> > We have tested on one of the test box.
> > With this patch, it doesn't crash kernel anymore, which is good!
> >
> > Howeve
On Sat, 2019-10-05 at 10:22 -0700, Alexander Duyck wrote:
> On Fri, Oct 4, 2019 at 7:18 PM David Z. Dai wrote:
> >
> > On Fri, 2019-10-04 at 16:36 -0700, Alexander Duyck wrote:
> > > From: Alexander Duyck
> > >
> > > This patch is meant to addre
On Fri, 2019-10-04 at 16:36 -0700, Alexander Duyck wrote:
> From: Alexander Duyck
>
> This patch is meant to address possible race conditions that can exist
> between network configuration and power management. A similar issue was
> fixed for igb in commit 9474933caf21 ("igb: close/suspend race i
On Fri, 2019-10-04 at 07:35 -0700, Alexander Duyck wrote:
> On Thu, Oct 3, 2019 at 5:02 PM David Z. Dai wrote:
> >
> > On Thu, 2019-10-03 at 13:39 -0700, Alexander Duyck wrote:
> > > On Thu, Oct 3, 2019 at 11:51 AM David Z. Dai
> > > wrote:
> > > &
On Thu, 2019-10-03 at 13:39 -0700, Alexander Duyck wrote:
> On Thu, Oct 3, 2019 at 11:51 AM David Z. Dai wrote:
> >
> > On Thu, 2019-10-03 at 10:39 -0700, Alexander Duyck wrote:
> > > On Thu, Oct 3, 2019 at 9:59 AM David Dai wrote:
> > > >
> > >
On Thu, 2019-10-03 at 10:39 -0700, Alexander Duyck wrote:
> On Thu, Oct 3, 2019 at 9:59 AM David Dai wrote:
> >
> > We see the behavior when EEH e1000e adapter detects io permanent failure,
> > it will crash kernel with this stack:
> > EEH: Beginning: 'error_detected(permanent failure)'
> > EEH: P
ATN:PLEASE/ I AM Mr Mohammad Z. Raqab
Before I introduce myself, I wish to inform you that this letter is not a hoax
mail and I urge you to treat it serious. This letter must , come to you as a
big surprise, but I believe it is only a day that people meet and become great
friends and business
On Fri, 2019-08-30 at 13:33 -0700, David Miller wrote:
> From: "David Z. Dai"
> Date: Fri, 30 Aug 2019 15:03:52 -0500
>
> > I have the impression that last parameter num value should be larger
> > than the attribute num value in 2nd parameter (TC_POLICE_RAT
On Fri, 2019-08-30 at 12:11 -0700, Cong Wang wrote:
> On Fri, Aug 30, 2019 at 12:06 PM David Dai wrote:
> > - if (p->peak_present)
> > + if ((police->params->rate.rate_bytes_ps >= (1ULL << 32)) &&
> > + nla_put_u64_64bit(skb, TCA_POLICE_RATE64,
> > +
On Thu, 2019-08-29 at 10:32 +0200, Eric Dumazet wrote:
>
> On 8/29/19 12:51 AM, David Dai wrote:
> > For high speed adapter like Mellanox CX-5 card, it can reach upto
> > 100 Gbits per second bandwidth. Currently htb already supports 64bit rate
> > in tc utility. However police action rate and pea
On 2/8/19 6:34 AM, Linus Walleij wrote:
> On Fri, Feb 8, 2019 at 12:54 PM Thomas Petazzoni
> wrote:
>
>> Hoan Tran's e-mail is bouncing:
>>
>> : host ASPMX.L.GOOGLE.COM[64.233.167.26] said: 550-5.2.1 The
>> email account that you tried to reach is disabled. Learn more at 550
>> 5.2.1
>>
ni Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Thursday, January 24, 2019 7:33 PM
> To: Stephen Rothwell ; Daniel Vetter
> ; Joonas Lahtinen ;
> Vivi, Rodrigo ; Intel Graphics
> ; DRI
> Cc: Linux Next Mailing List ; Linux Kernel
> Mailing List
> ; Li, Weinan Z ; Z
>
>
> > +static void free_extended_page_bitmap(struct virtio_balloon *vb) {
> > + int i, bmap_count = vb->nr_page_bmap;
> > +
> > + for (i = 1; i < bmap_count; i++) {
> > + kfree(vb->page_bitmap[i]);
> > + vb->page_bitmap[i] = NULL;
> > + vb->nr_page_bmap--;
> >
> On Wed, Jan 18, 2017 at 04:56:58AM +, Li, Liang Z wrote:
> > > > - virtqueue_add_outbuf(vq, &sg, 1, vb, GFP_KERNEL);
> > > > - virtqueue_kick(vq);
> > > > +static void do_set_resp_bitmap(struct virtio_balloon *vb,
> > >
> > > > > > Signed-off-by: Liang Li
> > > > > > Cc: Michael S. Tsirkin
> > > > > > Cc: Paolo Bonzini
> > > > > > Cc: Cornelia Huck
> > > > > > Cc: Amit Shah
> > > > > > Cc: Dave Hansen
> > > > > > Cc: Andrea Arcangeli
> > > > > > Cc: David Hildenbrand
> > > > > > ---
> > > > > > include/ua
> Am 21.12.2016 um 07:52 schrieb Liang Li:
> > This patch set contains two parts of changes to the virtio-balloon.
> >
> > One is the change for speeding up the inflating & deflating process,
> > the main idea of this optimization is to use {pfn|length} to present
> > the page information instead o
> > - virtqueue_add_outbuf(vq, &sg, 1, vb, GFP_KERNEL);
> > - virtqueue_kick(vq);
> > +static void do_set_resp_bitmap(struct virtio_balloon *vb,
> > + unsigned long base_pfn, int pages)
> >
> > - /* When host has read buffer, this completes via balloon_ack */
> > - wait_event(vb->
> Sent: Wednesday, January 18, 2017 3:11 AM
> To: Li, Liang Z
> Cc: k...@vger.kernel.org; virtio-...@lists.oasis-open.org; qemu-
> de...@nongnu.org; linux...@kvack.org; linux-kernel@vger.kernel.org;
> virtualizat...@lists.linux-foundation.org; amit.s...@redhat.com; Hansen,
>
> On 29/12/2016 10:25, Liang Li wrote:
> > x86-64 is currently limited physical address width to 46 bits, which
> > can support 64 TiB of memory. Some vendors require to support more for
> > some use case. Intel plans to extend the physical address width to
> > 52 bits in some of the future product
> On Wed, Dec 21, 2016 at 02:52:25PM +0800, Liang Li wrote:
> > Add a new feature which supports sending the page information with
> > range array. The current implementation uses PFNs array, which is not
> > very efficient. Using ranges can improve the performance of
> > inflating/deflating signif
Hi guys,
Could you help to review this patch set?
Thanks!
Liang
> -Original Message-
> From: Li, Liang Z
> Sent: Wednesday, December 21, 2016 2:52 PM
> To: k...@vger.kernel.org
> Cc: virtio-...@lists.oasis-open.org; qemu-de...@nongnu.org; linux-
> m...@kvack
> Subject: Re: [PATCH RFC 0/4] 5-level EPT
>
> On Thu, 29 Dec 2016 17:25:59 +0800, Liang Li said:
> > x86-64 is currently limited physical address width to 46 bits, which
> > can support 64 TiB of memory. Some vendors require to support more for
> > some use case. Intel plans to extend the physica
> Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for
> fast (de)inflating & fast live migration
>
> On Thu, Dec 15, 2016 at 05:40:45PM -0800, Dave Hansen wrote:
> > On 12/15/2016 05:38 PM, Li, Liang Z wrote:
> > >
> > > Use 52 bits f
> On Fri, Dec 16, 2016 at 01:12:21AM +, Li, Liang Z wrote:
> > There still exist the case if the MAX_ORDER is configured to a large
> > value, e.g. 36 for a system with huge amount of memory, then there is only
> 28 bits left for the pfn, which is not enough.
>
> No
> On 12/15/2016 05:38 PM, Li, Liang Z wrote:
> >
> > Use 52 bits for 'pfn', 12 bits for 'length', when the 12 bits is not long
> > enough
> for the 'length'
> > Set the 'length' to a special value to indicate the "act
> On 12/15/2016 04:48 PM, Li, Liang Z wrote:
> >>> It seems we leave too many bit for the pfn, and the bits leave for
> >>> length is not enough, How about keep 45 bits for the pfn and 19 bits
> >>> for length, 45 bits for pfn can cover 57 bits physical ad
> On Thu, Dec 15, 2016 at 07:34:33AM -0800, Dave Hansen wrote:
> > On 12/14/2016 12:59 AM, Li, Liang Z wrote:
> > >> Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend
> > >> virtio-balloon for fast (de)inflating & fast live migration
> > >>
> Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for
> fast (de)inflating & fast live migration
>
> On 12/14/2016 12:59 AM, Li, Liang Z wrote:
> >> Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon
> >> for fast (
> Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for
> fast (de)inflating & fast live migration
>
> On 12/08/2016 08:45 PM, Li, Liang Z wrote:
> > What's the conclusion of your discussion? It seems you want some
> > statistic before decidi
> fast (de)inflating & fast live migration
>
> Hello,
>
> On Fri, Dec 09, 2016 at 05:35:45AM +, Li, Liang Z wrote:
> > > On 12/08/2016 08:45 PM, Li, Liang Z wrote:
> > > > What's the conclusion of your discussion? It seems you want some
> >
> UMIP (User-Mode Instruction Prevention) is a feature of future Intel
> processors (Cannonlake?) that blocks SLDT, SGDT, STR, SIDT and SMSW from
> user-mode processes.
>
> The idea here is to use virtualization intercepts to emulate UMIP; it slows
> down the instructions when they're executed in
> On 12/08/2016 08:45 PM, Li, Liang Z wrote:
> > What's the conclusion of your discussion? It seems you want some
> > statistic before deciding whether to ripping the bitmap from the ABI,
> > am I right?
>
> I think Andrea and David feel pretty strongly that we sh
> > 1. Current patches do a hypercall for each order in the allocator.
> >This is inefficient, but independent from the underlying data
> >structure in the ABI, unless bitmaps are in play, which they aren't.
> > 2. Should we have bitmaps in the ABI, even if they are not in use by the
> >
> Subject: Re: [PATCH kernel v5 0/5] Extend virtio-balloon for fast
> (de)inflating
> & fast live migration
>
> On 12/07/2016 05:35 AM, Li, Liang Z wrote:
> >> Am 30.11.2016 um 09:43 schrieb Liang Li:
> >> IOW in real examples, do we have really large consecu
> Am 30.11.2016 um 09:43 schrieb Liang Li:
> > This patch set contains two parts of changes to the virtio-balloon.
> >
> > One is the change for speeding up the inflating & deflating process,
> > the main idea of this optimization is to use bitmap to send the page
> > information to host instead of
> >>> + mutex_lock(&vb->balloon_lock);
> >>> +
> >>> + for (order = MAX_ORDER - 1; order >= 0; order--) {
> >>
> >> I scratched my head for a bit on this one. Why are you walking over
> >> orders,
> >> *then* zones. I *think* you're doing it because you can efficiently
> >> fill the bitmaps at a
> On 11/30/2016 12:43 AM, Liang Li wrote:
> > +static void send_unused_pages_info(struct virtio_balloon *vb,
> > + unsigned long req_id)
> > +{
> > + struct scatterlist sg_in;
> > + unsigned long pos = 0;
> > + struct virtqueue *vq = vb->req_vq;
> > + struct virtio
> On 11/06/2016 07:37 PM, Li, Liang Z wrote:
> >> Let's say we do a 32k bitmap that can hold ~1M pages. That's 4GB of RAM.
> >> On a 1TB system, that's 256 passes through the top-level loop.
> >> The bottom-level lists have tens of thousands of pages
> Please squish this and patch 5 together. It makes no sense to separate them.
>
OK.
> > +static void send_unused_pages_info(struct virtio_balloon *vb,
> > + unsigned long req_id)
> > +{
> > + struct scatterlist sg_in;
> > + unsigned long pfn = 0, bmap_len, pfn_lim
> On 10/26/2016 03:06 AM, Li, Liang Z wrote:
> > I am working on Dave's new bitmap schema, I have finished the part of
> > getting the 'hybrid scheme bitmap' and found the complexity was more
> > than I expected. The main issue is more memory is required t
.@redhat.com
> Subject: Re: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast
> (de)inflating & fast live migration
>
> On 10/26/2016 03:13 AM, Li, Liang Z wrote:
> > 3 times memory required is not accurate, please ignore this. sorry ...
> > The complexity is the
> > On 10/20/2016 11:24 PM, Liang Li wrote:
> > > Dave Hansen suggested a new scheme to encode the data structure,
> > > because of additional complexity, it's not implemented in v3.
> >
> > So, what do you want done with this patch set? Do you want it applied
> > as-is so that we can introduce a
> On 10/20/2016 11:24 PM, Liang Li wrote:
> > Dave Hansen suggested a new scheme to encode the data structure,
> > because of additional complexity, it's not implemented in v3.
>
> So, what do you want done with this patch set? Do you want it applied as-is
> so that we can introduce a new host/gu
> > +static inline void init_pfn_range(struct virtio_balloon *vb) {
> > + vb->min_pfn = ULONG_MAX;
> > + vb->max_pfn = 0;
> > +}
> > +
> > +static inline void update_pfn_range(struct virtio_balloon *vb,
> > +struct page *page)
> > +{
> > + unsigned long balloon_pfn
> On 10/20/2016 11:24 PM, Liang Li wrote:
> > Expose the function to get the max pfn, so it can be used in the
> > virtio-balloon device driver. Simply include the 'linux/bootmem.h'
> > is not enough, if the device driver is built to a module, directly
> > refer the max_pfn lead to build failed.
>
> On 10/20/2016 11:24 PM, Liang Li wrote:
> > Add a new feature which supports sending the page information with a
> > bitmap. The current implementation uses PFNs array, which is not very
> > efficient. Using bitmap can improve the performance of
> > inflating/deflating significantly
>
> Why is i
> On 10/20/2016 11:24 PM, Liang Li wrote:
> > Will allow faster notifications using a bitmap down the road.
> > balloon_pfn_to_page() can be removed because it's useless.
>
> This is a pretty terse description of what's going on here. Could you try to
> elaborate a bit? What *is* the current app
> On Fri, Oct 21, 2016 at 10:25:21AM -0700, Dave Hansen wrote:
> > On 10/20/2016 11:24 PM, Liang Li wrote:
> > > Dave Hansen suggested a new scheme to encode the data structure,
> > > because of additional complexity, it's not implemented in v3.
> >
> > So, what do you want done with this patch set
Intel SDM doesn't describe whether the A bit will be set or not when CPU
accesses a no present EPT page table entry?
even this patch works for the current CPU, it's not good to make such an
assumption.
Should we revert it?
Thanks!
Liang
> -Original Message-
> From: kvm-ow...@vger.k
> Subject: Re: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast
> (de)inflating
> & fast live migration
>
> 2016-08-08 14:35 GMT+08:00 Liang Li :
> > This patch set contains two parts of changes to the virtio-balloon.
> >
> > One is the change for speeding up the inflating & deflating process
Hi Michael,
I know you are very busy. If you have time, could you help to take a look at
this patch set?
Thanks!
Liang
> -Original Message-
> From: Li, Liang Z
> Sent: Thursday, August 18, 2016 9:06 AM
> To: Michael S. Tsirkin
> Cc: virtualizat...@lists.linux-founda
Hi Michael,
Could you help to review this version when you have time?
Thanks!
Liang
> -Original Message-
> From: Li, Liang Z
> Sent: Monday, August 08, 2016 2:35 PM
> To: linux-kernel@vger.kernel.org
> Cc: virtualizat...@lists.linux-foundation.org; linux...@kvack.o
> Subject: Re: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast
> (de)inflating
> & fast live migration
>
> On 08/07/2016 11:35 PM, Liang Li wrote:
> > Dave Hansen suggested a new scheme to encode the data structure,
> > because of additional complexity, it's not implemented in v3.
>
> FWIW,
> > It's only small because it makes you rescan the free list.
> > So maybe you should do something else.
> > I looked at it a bit. Instead of scanning the free list, how about
> > scanning actual page structures? If page is unused, pass it to host.
> > Solves the problem of rescanning multiple tim
> > > On Wed, Jul 27, 2016 at 09:03:21AM -0700, Dave Hansen wrote:
> > > > On 07/26/2016 06:23 PM, Liang Li wrote:
> > > > > + vb->pfn_limit = VIRTIO_BALLOON_PFNS_LIMIT;
> > > > > + vb->pfn_limit = min(vb->pfn_limit, get_max_pfn());
> > > > > + vb->bmap_len = ALIGN(vb->pfn_limit, BITS_P
> On Thu, Jul 28, 2016 at 06:36:18AM +, Li, Liang Z wrote:
> > > > > This ends up doing a 1MB kmalloc() right? That seems a _bit_ big.
> > > > > How big was the pfn buffer before?
> > > >
> > > > Yes, it is if the max pfn is more than 3
> On Thu, Jul 28, 2016 at 03:06:37AM +, Li, Liang Z wrote:
> > > > + * VIRTIO_BALLOON_PFNS_LIMIT is used to limit the size of page
> > > > +bitmap
> > > > + * to prevent a very large page bitmap, there are two reasons for this:
> > > > + *
> > }
> >
> > +static void update_free_pages_stats(struct virtio_balloon *vb,
>
> why _stats?
Will change.
> > + max_pfn = get_max_pfn();
> > + mutex_lock(&vb->balloon_lock);
> > + while (pfn < max_pfn) {
> > + memset(vb->page_bitmap, 0, vb->bmap_len);
> > + ret = get_
> > > This ends up doing a 1MB kmalloc() right? That seems a _bit_ big.
> > > How big was the pfn buffer before?
> >
> > Yes, it is if the max pfn is more than 32GB.
> > The size of the pfn buffer use before is 256*4 = 1024 Bytes, it's too
> > small, and it's the main reason for bad performance.
>
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 7da61ad..3ad8b10
> > 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -4523,6 +4523,52 @@ unsigned long get_max_pfn(void) }
> > EXPORT_SYMBOL(get_max_pfn);
> >
> > +static void mark_free_pages_bitmap(struct zone *zone, unsig
> On 07/27/2016 03:05 PM, Michael S. Tsirkin wrote:
> > On Wed, Jul 27, 2016 at 09:40:56AM -0700, Dave Hansen wrote:
> >> On 07/26/2016 06:23 PM, Liang Li wrote:
> >>> + for_each_migratetype_order(order, t) {
> >>> + list_for_each(curr, &zone->free_area[order].free_list[t]) {
> >>> +
> > +/*
> > + * VIRTIO_BALLOON_PFNS_LIMIT is used to limit the size of page bitmap
> > + * to prevent a very large page bitmap, there are two reasons for this:
> > + * 1) to save memory.
> > + * 2) allocate a large bitmap may fail.
> > + *
> > + * The actual limit of pfn is determined by:
> > + * p
> Subject: Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate
> process
>
> On Wed, Jul 27, 2016 at 09:03:21AM -0700, Dave Hansen wrote:
> > On 07/26/2016 06:23 PM, Liang Li wrote:
> > > + vb->pfn_limit = VIRTIO_BALLOON_PFNS_LIMIT;
> > > + vb->pfn_limit = min(vb->pfn_limit, get_max
> > + * VIRTIO_BALLOON_PFNS_LIMIT is used to limit the size of page bitmap
> > + * to prevent a very large page bitmap, there are two reasons for this:
> > + * 1) to save memory.
> > + * 2) allocate a large bitmap may fail.
> > + *
> > + * The actual limit of pfn is determined by:
> > + * pfn_limit
> Subject: Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate
> process
>
> On 07/26/2016 06:23 PM, Liang Li wrote:
> > + vb->pfn_limit = VIRTIO_BALLOON_PFNS_LIMIT;
> > + vb->pfn_limit = min(vb->pfn_limit, get_max_pfn());
> > + vb->bmap_len = ALIGN(vb->pfn_limit, BITS_PER_LON
> Subject: Re: [PATCH v2 repost 6/7] mm: add the related functions to get free
> page info
>
> On 07/26/2016 06:23 PM, Liang Li wrote:
> > + for_each_migratetype_order(order, t) {
> > + list_for_each(curr, &zone->free_area[order].free_list[t]) {
> > + pfn = page_to_pf
> So I'm fine with this patchset, but I noticed it was not yet reviewed by MM
> people. And that is not surprising since you did not copy memory
> management mailing list on it.
>
> I added linux...@kvack.org Cc on this mail but this might not be enough.
>
> Please repost (e.g. [PATCH v2 repost])
Hi Michael,
If you have time, could you help to review this patch set?
Thanks!
Liang
> -Original Message-
> From: Li, Liang Z
> Sent: Wednesday, June 29, 2016 6:32 PM
> To: m...@redhat.com
> Cc: linux-kernel@vger.kernel.org; virtualizat...@lists.linux-foun
ettings from DHCP server
> if IPv6 is enabled on "Dumb AP" board. If IPv6 is disabled I may see that
> wireless client sends "DHCP Discover" then server replies with "DHCP Offer"
> but
> that offer never reaches wireless client.
Do you have WDS enabled? If not, DHCP has issues in that scenario:
https://wiki.openwrt.org/doc/howto/clientmode
Aaron Z
Ping ...
Liang
> -Original Message-
> From: Li, Liang Z
> Sent: Wednesday, June 29, 2016 6:32 PM
> To: m...@redhat.com
> Cc: linux-kernel@vger.kernel.org; virtualizat...@lists.linux-foundation.org;
> k...@vger.kernel.org; qemu-de...@nongnu.org; virtio-dev@lists.oasis-
Hi Michael,
Thanks for your comments!
>
> 2<< 30 is 2G but that is not a useful comment.
> pls explain what is the reason for this selection.
>
Will change in the next version.
> > +struct balloon_bmap_hdr {
> > + __virtio32 id;
> > + __virtio32 page_shift;
> > + __virtio64 start_pfn;
Hi Michael,
Could you help to review this patch set and give some comments when you have
time?
My work is blocked here.
Thanks !
Liang
> -Original Message-
> From: Li, Liang Z
> Sent: Monday, June 13, 2016 5:47 PM
> To: k...@vger.kernel.org
> Cc: virtio-...@lists.oasis
Any comments?
Liang
> -Original Message-
> From: Li, Liang Z
> Sent: Monday, June 13, 2016 5:47 PM
> To: k...@vger.kernel.org
> Cc: virtio-...@lists.oasis-open.org; qemu-de...@nongun.org; linux-
> ker...@vger.kernel.org; m...@redhat.com; Li, Liang Z
> Subject: [PA
Ping ...
Liang
> -Original Message-
> From: Li, Liang Z
> Sent: Monday, June 13, 2016 5:47 PM
> To: k...@vger.kernel.org
> Cc: virtio-...@lists.oasis-open.org; qemu-de...@nongun.org; linux-
> ker...@vger.kernel.org; m...@redhat.com; Li, Liang Z; Paolo Bonzini; Cor
Ping...
Liang
> -Original Message-
> From: Li, Liang Z
> Sent: Wednesday, June 01, 2016 10:41 AM
> To: linux-kernel@vger.kernel.org
> Cc: k...@vger.kernel.org; qemu-de...@nongnu.org; Michael S. Tsirkin;
> Paolo Bonzini; Cornelia Huck; Amit Shah
> Subject: RE:
Hi Will,
On Mon, Jun 6, 2016 at 10:05 AM, Will Deacon wrote:
> On Sat, Jun 04, 2016 at 03:00:29PM -0700, Zi Shen Lim wrote:
>> Remove superfluous stack frame, saving us 3 instructions for
>> every JMP_CALL.
>>
>> Signed-off-by: Zi Shen Lim
>> ---
>> arch/arm64/net/bpf_jit_comp.c | 3 ---
>> 1 f
of
>> 'ERR_PTR' was here
>> return ERR_PTR(-EOPNOTSUPP);
>> ^
>> cc1: some warnings being treated as errors
>
>
> Looks like including linux/bpf.h at the very beginning causes issues when
> bpf
> syscall is disabled. We
conservative?
Liang
> -Original Message-
> From: Li, Liang Z
> Sent: Friday, May 27, 2016 6:34 PM
> To: linux-kernel@vger.kernel.org
> Cc: k...@vger.kernel.org; qemu-de...@nongnu.org; Li, Liang Z; Michael S.
> Tsirkin; Paolo Bonzini; Cornelia Huck; Amit Shah
> Subj
> > > Interesting. How about instead of tell host, we do multiple scans,
> > > each time ignoring pages out of range?
> > >
> > > for (pfn = min pfn; pfn < max pfn; pfn += 1G) {
> > > foreach page
> > > if page pfn < pfn || page pfn >= pfn + 1G
> > >
> > > >
> > > > Hi MST,
> > > >
> > > > I have measured the performance when using a 32K page bitmap,
> > >
> > > Just to make sure. Do you mean a 32Kbyte bitmap?
> > > Covering 1Gbyte of memory?
> > Yes.
> >
> > >
> > > > and inflate the balloon to 3GB
> > > > of an idle guest with 4GB RAM.
> > >
> On Wed, May 25, 2016 at 08:48:17AM +, Li, Liang Z wrote:
> > > > > Suggestion to address all above comments:
> > > > > 1. allocate a bunch of pages and link them up,
> > > > > calculating the min and the max pfn.
> > >
> > > Suggestion to address all above comments:
> > > 1. allocate a bunch of pages and link them up,
> > > calculating the min and the max pfn.
> > > if max-min exceeds the allocated bitmap size,
> > > tell host.
> >
> > I am not sure if it works well in some cases, e.g. The alloca
> > > > > > > This is grossly inefficient if you only requested a single page.
> > > > > > > And it's also allocating memory very aggressively without
> > > > > > > ever telling the host what is going on.
> > > > > >
> > > > > > If only requested a single page, there is no need to send the
> > > >
1 - 100 of 297 matches
Mail list logo
