On Mon, Aug 12, 2024 at 3:00 PM Jason Wang wrote:
>
> On Thu, Aug 8, 2024 at 6:52 PM Yongji Xie wrote:
> >
> > On Thu, Aug 8, 2024 at 10:58 AM Jason Wang wrote:
> > >
> > > On Wed, Aug 7, 2024 at 2:52 PM Yongji Xie wrote:
> > > >
> > > > On Mon, Aug 5, 2024 at 4:21 PM Jason Wang wrote:
> > > >
On Thu, Aug 8, 2024 at 6:52 PM Yongji Xie wrote:
>
> On Thu, Aug 8, 2024 at 10:58 AM Jason Wang wrote:
> >
> > On Wed, Aug 7, 2024 at 2:52 PM Yongji Xie wrote:
> > >
> > > On Mon, Aug 5, 2024 at 4:21 PM Jason Wang wrote:
> > > >
> > > > Barry said [1]:
> > > >
> > > > """
> > > > mm doesn't sup
On Thu, Aug 8, 2024 at 7:09 PM Yongji Xie wrote:
>
> On Thu, Aug 8, 2024 at 1:50 PM Jason Wang wrote:
> >
> > On Wed, Aug 7, 2024 at 2:54 PM Yongji Xie wrote:
> > >
> > > On Wed, Aug 7, 2024 at 12:38 PM Jason Wang wrote:
> > > >
> > > > On Wed, Aug 7, 2024 at 11:13 AM Yongji Xie
> > > > wrote
On Thu, Aug 8, 2024 at 1:50 PM Jason Wang wrote:
>
> On Wed, Aug 7, 2024 at 2:54 PM Yongji Xie wrote:
> >
> > On Wed, Aug 7, 2024 at 12:38 PM Jason Wang wrote:
> > >
> > > On Wed, Aug 7, 2024 at 11:13 AM Yongji Xie
> > > wrote:
> > > >
> > > > On Wed, Aug 7, 2024 at 10:39 AM Jason Wang wrote:
On Thu, Aug 8, 2024 at 10:58 AM Jason Wang wrote:
>
> On Wed, Aug 7, 2024 at 2:52 PM Yongji Xie wrote:
> >
> > On Mon, Aug 5, 2024 at 4:21 PM Jason Wang wrote:
> > >
> > > Barry said [1]:
> > >
> > > """
> > > mm doesn't support non-blockable __GFP_NOFAIL allocation. Because
> > > __GFP_NOFAIL w
Hi, MST!
> > include/linux/virtio_vsock.h| 2 +-
> > include/net/af_vsock.h | 25 ++-
> > include/uapi/linux/virtio_vsock.h | 1 +
> > include/uapi/linux/vm_sockets.h | 14 ++
> > net/vmw_vsock/af_vsock.c| 116 +--
> > net/v
On 4/23/24 17:13, Michael S. Tsirkin wrote:
On Tue, Apr 23, 2024 at 11:41:07AM +0800, zhenwei pi wrote:
[snip]
#define VIRTIO_BALLOON_S_NAMES_WITH_PREFIX(VIRTIO_BALLOON_S_NAMES_prefix) { \
VIRTIO_BALLOON_S_NAMES_prefix "swap-in", \
Looks like a useful extension. But
any UAPI ext
On 4/22/24 15:47, David Hildenbrand wrote:
On 22.04.24 09:42, zhenwei pi wrote:
All the VM events related statistics have dependence on
'CONFIG_VM_EVENT_COUNTERS', once any stack variable is required by any
VM events in future, we would have codes like:
#ifdef CONFIG_VM_EVENT_COUNTERS
On 4/15/24 23:01, David Hildenbrand wrote:
On 15.04.24 10:41, zhenwei pi wrote:
Hi,
When the guest runs under critial memory pressure, the guest becomss
too slow, even sshd turns D state(uninterruptible) on memory
allocation. We can't login this VM to do any work on trouble shooting.
Guest
On Thu, Apr 11, 2024 at 03:03:31PM -0700, Andrew Morton
wrote:
> A large increase in the maximum number of processes.
The change from (some) default to effective infinity is the crux of the
change. Because that is only a number.
(Thus I don't find the number's 12700% increase alone a big change.
Hello.
On Mon, Apr 08, 2024 at 01:29:55PM -0700, Andrew Morton
wrote:
> That seems like a large change.
In what sense is it large?
I tried to lookup the code parts that depend on this default and either
add the other patches or mention the impact (that part could be more
thorough) in the commi
>> >> >[...]
>> >> >> >I think my understanding based on what Eric depicted differs from =
>you:
>> >> >> >we're supposed to filter out those many invalid cases and only tra=
>ce
>> >> >> >the valid action of sending a icmp, so where to add a new tracepoi=
>nt
>> >> >> >is important instead of addi
On Thu, Apr 11, 2024 at 12:57 PM Peilin He wrote:
>
> >> >[...]
> >> >> >I think my understanding based on what Eric depicted differs from you:
> >> >> >we're supposed to filter out those many invalid cases and only trace
> >> >> >the valid action of sending a icmp, so where to add a new tracepoin
>> >[...]
>> >> >I think my understanding based on what Eric depicted differs from you:
>> >> >we're supposed to filter out those many invalid cases and only trace
>> >> >the valid action of sending a icmp, so where to add a new tracepoint
>> >> >is important instead of adding more checks in the tr
On Thu, Apr 11, 2024 at 10:34 AM Peilin He wrote:
>
> >[...]
> >> >I think my understanding based on what Eric depicted differs from you:
> >> >we're supposed to filter out those many invalid cases and only trace
> >> >the valid action of sending a icmp, so where to add a new tracepoint
> >> >is i
>[...]
>> >I think my understanding based on what Eric depicted differs from you:
>> >we're supposed to filter out those many invalid cases and only trace
>> >the valid action of sending a icmp, so where to add a new tracepoint
>> >is important instead of adding more checks in the tracepoint itself
On Tue, 09 Apr 2024 10:34:06 -0500, Haitao Huang
wrote:
On Tue, 09 Apr 2024 04:03:22 -0500, Michal Koutný
wrote:
On Mon, Apr 08, 2024 at 11:23:21PM -0500, Haitao Huang
wrote:
It's always non-NULL based on testing.
It's hard for me to say definitely by reading the code. But IIUC
cgrou
[...]
> >I think my understanding based on what Eric depicted differs from you:
> >we're supposed to filter out those many invalid cases and only trace
> >the valid action of sending a icmp, so where to add a new tracepoint
> >is important instead of adding more checks in the tracepoint itself.
> >
>> From: hepeilin
>>
>> Introduce a tracepoint for icmp_send, which can help users to get more
>> detail information conveniently when icmp abnormal events happen.
>>
>> 1. Giving an usecase example:
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>=3D=3D=3D=3D=3D
>> W
On Tue, 09 Apr 2024 04:03:22 -0500, Michal Koutný wrote:
On Mon, Apr 08, 2024 at 11:23:21PM -0500, Haitao Huang
wrote:
It's always non-NULL based on testing.
It's hard for me to say definitely by reading the code. But IIUC
cgroup_disable command-line only blocks operations in /sys/fs/cgroup
On Mon, Apr 08, 2024 at 11:23:21PM -0500, Haitao Huang
wrote:
> It's always non-NULL based on testing.
>
> It's hard for me to say definitely by reading the code. But IIUC
> cgroup_disable command-line only blocks operations in /sys/fs/cgroup so user
> space can't set up controllers and config l
On Wed, Apr 3, 2024 at 10:47 AM tab wrote:
>
> > >
> > > On Fri, Mar 29, 2024 at 11:55:50AM +0800, Jason Wang wrote:
> > > > On Wed, Mar 27, 2024 at 5:08 PM Jason Wang wrote:
> > > > >
> > > > > On Thu, Mar 21, 2024 at 3:00 PM Michael S. Tsirkin
> > > > > wrote:
> > > > > >
> > > > > > On Wed,
On Tue, 02 Apr 2024 12:40:03 -0500, Michal Koutný wrote:
On Tue, Apr 02, 2024 at 11:20:21AM -0500, Haitao Huang
wrote:
Do we really want to have it implemented in c?
I only pointed to the available C boilerplate.
There are much fewer lines of
code in shell scripts. Note we are not really
On Tue, Apr 02, 2024 at 11:20:21AM -0500, Haitao Huang
wrote:
> Do we really want to have it implemented in c?
I only pointed to the available C boilerplate.
> There are much fewer lines of
> code in shell scripts. Note we are not really testing basic cgroup stuff.
> All we needed were creating
Hello.
On Sat, Mar 30, 2024 at 01:26:08PM +0200, Jarkko Sakkinen
wrote:
> > > It'd be more complicated and less readable to do all the stuff without
> > > the
> > > cgroup-tools, esp cgexec. I checked dependency, cgroup-tools only depends
> > >
> > > on libc so I hope this would not cause
>>
>> Introduce a tracepoint for icmp_send, which can help users to get more
>> detail information conveniently when icmp abnormal events happen.
>>
>> 1. Giving an usecase example:
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>=3D=3D=3D=3D=3D
>> When an application
>> >> -
>> >> v2->v3:
>> >> Some fixes according to
>> >> https://lore.kernel.org/all/20240319102549.7f7f6...@gandalf.local.home=
>/
>> >> 1. Change the tracking directory to/sys/kernel/tracking.
>> >> 2. Adjust the layout of the TP-STRUCT_entry parameter structure.
>> >>
>> >> v1->v2:
>> >
On Mon, Mar 25, 2024 at 12:05 PM Peilin He wrote:
>
> >> -
> >> v2->v3:
> >> Some fixes according to
> >> https://lore.kernel.org/all/20240319102549.7f7f6...@gandalf.local.home/
> >> 1. Change the tracking directory to/sys/kernel/tracking.
> >> 2. Adjust the layout of the TP-STRUCT_entry p
>>
>> Introduce a tracepoint for icmp_send, which can help users to get more
>> detail information conveniently when icmp abnormal events happen.
>>
>> 1. Giving an usecase example:
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>=3D=3D=3D=3D=3D
>> When an application
>> -
>> v2->v3:
>> Some fixes according to
>> https://lore.kernel.org/all/20240319102549.7f7f6...@gandalf.local.home/
>> 1. Change the tracking directory to/sys/kernel/tracking.
>> 2. Adjust the layout of the TP-STRUCT_entry parameter structure.
>>
>> v1->v2:
>> Some fixes according to
>> h
> > From: Peilin He
> >
> > Introduce a tracepoint for icmp_send, which can help users to get more
> > detail information conveniently when icmp abnormal events happen.
> >
> > 1. Giving an usecase example:
> > =
> > When an application experiences packet loss due to a
On Thu, Feb 01, 2024 at 12:47:39PM +0100, Tobias Huschle wrote:
> On Thu, Feb 01, 2024 at 03:08:07AM -0500, Michael S. Tsirkin wrote:
> > On Thu, Feb 01, 2024 at 08:38:43AM +0100, Tobias Huschle wrote:
> > > On Sun, Jan 21, 2024 at 01:44:32PM -0500, Michael S. Tsirkin wrote:
> > > > On Mon, Jan 08,
Hi SeongJae,
I couldn't send email to LKML properly due to internal system issues,
but it's better now so I will be able to communicate better.
On Wed, 6 Mar 2024 19:05:50 -0800 SeongJae Park wrote:
>
> Hello,
>
> On Tue, 27 Feb 2024 15:51:20 -0800 SeongJae Park wrote:
>
> > On Mon, 26 Feb
> > include/trace/events/icmp.h | 57
> > +
> > net/ipv4/icmp.c | 4
> > 2 files changed, 61 insertions(+)
> > create mode 100644 include/trace/events/icmp.h
> >
> > diff --git a/include/trace/events/icmp.h b/include/trace/events/icm
> > include/trace/events/icmp.h | 57
> > +
> > net/ipv4/icmp.c | 4
> > 2 files changed, 61 insertions(+)
> > create mode 100644 include/trace/events/icmp.h
> >
> > diff --git a/include/trace/events/icmp.h b/include/trace/events/icmp
Hello.
On Mon, Feb 26, 2024 at 03:48:18PM -0600, Haitao Huang
wrote:
> In case of overcomitting, i.e., sum of limits greater than the EPC capacity,
> if one group has a fault, and its usage is not above its own limit
> (try_charge() passes), yet total usage of the system has exceeded the
> capac
On Thu, Feb 01, 2024 at 12:47:39PM +0100, Tobias Huschle wrote:
> I'll do some more testing with the cond_resched->schedule fix, check the
> cgroup thing and wait for Peter then.
> Will get back if any of the above yields some results.
As I predicted, if you want attention from sched guys you need
On Wed, 21 Feb 2024 11:37:22 +, wangyunjian wrote:
> > -Original Message-
> > From: Xuan Zhuo [mailto:xuanz...@linux.alibaba.com]
> > Sent: Wednesday, February 21, 2024 5:53 PM
> > To: wangyunjian
> > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > k...@vger.kernel.org;
On Tue, 2024-02-20 at 14:18 +0100, Michal Koutný wrote:
> On Tue, Feb 20, 2024 at 09:52:39AM +, "Huang, Kai"
> wrote:
> > I am not sure, but is it possible or legal for an ancestor to have less
> > limit
> > than children?
>
> Why not?
> It is desired for proper hiearchical delegation and t
On Tue, Feb 20, 2024 at 09:52:39AM +, "Huang, Kai"
wrote:
> I am not sure, but is it possible or legal for an ancestor to have less limit
> than children?
Why not?
It is desired for proper hiearchical delegation and the tightest limit
of ancestors applies (cf memory.max).
Michal
signature
On Wed, Feb 07, 2024 at 11:27:14AM +0800, Jason Wang wrote:
On Tue, Feb 6, 2024 at 10:52 PM Stefano Garzarella wrote:
If VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK is not negotiated, we expect
the driver to enable virtqueue before setting DRIVER_OK. If the driver
tries anyway, better to fail right
On Tue, Feb 06, 2024 at 10:56:50AM -0500, Michael S. Tsirkin wrote:
better @subj: try late vq enable only if negotiated
I rewrote it 3/4 times, and before sending it I was not happy with the
result.
Thank you, much better! I'll change it in v2.
Stefano
On Thu, Feb 01, 2024 at 12:47:39PM +0100, Tobias Huschle wrote:
> On Thu, Feb 01, 2024 at 03:08:07AM -0500, Michael S. Tsirkin wrote:
> > On Thu, Feb 01, 2024 at 08:38:43AM +0100, Tobias Huschle wrote:
> > > On Sun, Jan 21, 2024 at 01:44:32PM -0500, Michael S. Tsirkin wrote:
> > > > On Mon, Jan 08,
On Thu, Feb 01, 2024 at 03:08:07AM -0500, Michael S. Tsirkin wrote:
> On Thu, Feb 01, 2024 at 08:38:43AM +0100, Tobias Huschle wrote:
> > On Sun, Jan 21, 2024 at 01:44:32PM -0500, Michael S. Tsirkin wrote:
> > > On Mon, Jan 08, 2024 at 02:13:25PM +0100, Tobias Huschle wrote:
> > > > On Thu, Dec 14,
On Thu, Feb 01, 2024 at 08:38:43AM +0100, Tobias Huschle wrote:
> On Sun, Jan 21, 2024 at 01:44:32PM -0500, Michael S. Tsirkin wrote:
> > On Mon, Jan 08, 2024 at 02:13:25PM +0100, Tobias Huschle wrote:
> > > On Thu, Dec 14, 2023 at 02:14:59AM -0500, Michael S. Tsirkin wrote:
> > > - Along with the
On Sun, Jan 21, 2024 at 01:44:32PM -0500, Michael S. Tsirkin wrote:
> On Mon, Jan 08, 2024 at 02:13:25PM +0100, Tobias Huschle wrote:
> > On Thu, Dec 14, 2023 at 02:14:59AM -0500, Michael S. Tsirkin wrote:
> > - Along with the wakeup of the kworker, need_resched needs to
> > be set, such that con
On Mon, Jan 29, 2024 at 04:18:36PM +0530, Deepak Kumar Singh
wrote:
> There is already a patch posted for similar problem -
> https://lore.kernel.org/all/20231201110631.669085-1-quic_dee...@quicinc.com/
I was not aware, thanks for the pointer.
Do you plan to update your patch to "just" bail-out
Hi Steve,
On 25 Jan 15:44, Steven Rostedt wrote:
> On Thu, 25 Jan 2024 17:16:21 -0300
> "Ricardo B. Marliere" wrote:
>
> > Now that trace_seq_reset have been created, correct the places where the
> > buffers need to be initialized.
>
> This patch would need to come first. You don't ever want to
On Sun, Jan 21, 2024 at 01:44:32PM -0500, Michael S. Tsirkin wrote:
> On Mon, Jan 08, 2024 at 02:13:25PM +0100, Tobias Huschle wrote:
> > On Thu, Dec 14, 2023 at 02:14:59AM -0500, Michael S. Tsirkin wrote:
> > >
> > > Peter, would appreciate feedback on this. When is cond_resched()
> > > insuffici
On Mon, Jan 22, 2024 at 11:47:22AM +0100, Eugenio Perez Martin wrote:
On Mon, Jan 22, 2024 at 11:22 AM Stefano Garzarella wrote:
On Wed, Jan 17, 2024 at 11:23:23AM -0800, Steve Sistare wrote:
>vdpasim_do_reset sets running to true, which is wrong, as it allows
>vdpasim_kick_vq to post work req
On Mon, Jan 08, 2024 at 02:13:25PM +0100, Tobias Huschle wrote:
> On Thu, Dec 14, 2023 at 02:14:59AM -0500, Michael S. Tsirkin wrote:
> >
> > Peter, would appreciate feedback on this. When is cond_resched()
> > insufficient to give up the CPU? Should
> > Documentation/kernel-hacking/hacking.rst
>
On Mon, Jan 08, 2024 at 02:13:25PM +0100, Tobias Huschle wrote:
> On Thu, Dec 14, 2023 at 02:14:59AM -0500, Michael S. Tsirkin wrote:
> >
> > Peter, would appreciate feedback on this. When is cond_resched()
> > insufficient to give up the CPU? Should
> > Documentation/kernel-hacking/hacking.rst
>
On Thu, Dec 14, 2023 at 02:14:59AM -0500, Michael S. Tsirkin wrote:
>
> Peter, would appreciate feedback on this. When is cond_resched()
> insufficient to give up the CPU? Should
> Documentation/kernel-hacking/hacking.rst
> be updated to require schedule() instead?
>
Happy new year everybody!
On 12.12.2023 10:32, Marco Elver wrote:
> On Tue, 12 Dec 2023 at 10:19, Paul Heidekrüger
> wrote:
> >
> > On 12.12.2023 00:37, Andrey Konovalov wrote:
> > > On Tue, Dec 12, 2023 at 12:35 AM Paul Heidekrüger
> > > wrote:
> > > >
> > > > Using CONFIG_FTRACE=y instead of CONFIG_TRACEPOINTS=y produc
On Wed, Dec 13, 2023 at 09:55:23AM -0500, Michael S. Tsirkin wrote:
> On Wed, Dec 13, 2023 at 01:45:35PM +0100, Tobias Huschle wrote:
> > On Wed, Dec 13, 2023 at 07:00:53AM -0500, Michael S. Tsirkin wrote:
> > > On Wed, Dec 13, 2023 at 11:37:23AM +0100, Tobias Huschle wrote:
> > > > On Tue, Dec 12,
On Wed, Dec 13, 2023 at 01:45:35PM +0100, Tobias Huschle wrote:
> On Wed, Dec 13, 2023 at 07:00:53AM -0500, Michael S. Tsirkin wrote:
> > On Wed, Dec 13, 2023 at 11:37:23AM +0100, Tobias Huschle wrote:
> > > On Tue, Dec 12, 2023 at 11:15:01AM -0500, Michael S. Tsirkin wrote:
> > > > On Tue, Dec 12,
On Wed, Dec 13, 2023 at 01:45:35PM +0100, Tobias Huschle wrote:
> On Wed, Dec 13, 2023 at 07:00:53AM -0500, Michael S. Tsirkin wrote:
> > On Wed, Dec 13, 2023 at 11:37:23AM +0100, Tobias Huschle wrote:
> > > On Tue, Dec 12, 2023 at 11:15:01AM -0500, Michael S. Tsirkin wrote:
> > > > On Tue, Dec 12,
On Wed, Dec 13, 2023 at 07:00:53AM -0500, Michael S. Tsirkin wrote:
> On Wed, Dec 13, 2023 at 11:37:23AM +0100, Tobias Huschle wrote:
> > On Tue, Dec 12, 2023 at 11:15:01AM -0500, Michael S. Tsirkin wrote:
> > > On Tue, Dec 12, 2023 at 11:00:12AM +0800, Jason Wang wrote:
> > > > On Tue, Dec 12, 202
On Wed, Dec 13, 2023 at 11:37:23AM +0100, Tobias Huschle wrote:
> On Tue, Dec 12, 2023 at 11:15:01AM -0500, Michael S. Tsirkin wrote:
> > On Tue, Dec 12, 2023 at 11:00:12AM +0800, Jason Wang wrote:
> > > On Tue, Dec 12, 2023 at 12:54 AM Michael S. Tsirkin
> > > wrote:
>
> We played around with t
On Tue, Dec 12, 2023 at 11:15:01AM -0500, Michael S. Tsirkin wrote:
> On Tue, Dec 12, 2023 at 11:00:12AM +0800, Jason Wang wrote:
> > On Tue, Dec 12, 2023 at 12:54 AM Michael S. Tsirkin wrote:
We played around with the suggestions and some other ideas.
I would like to share some initial results.
On Tue, Dec 12, 2023 at 11:00:12AM +0800, Jason Wang wrote:
> On Tue, Dec 12, 2023 at 12:54 AM Michael S. Tsirkin wrote:
> >
> > On Mon, Dec 11, 2023 at 03:26:46PM +0800, Jason Wang wrote:
> > > > Try reducing the VHOST_NET_WEIGHT limit and see if that improves things
> > > > any?
> > >
> > > Or
On Tue, Dec 12, 2023 at 12:54 AM Michael S. Tsirkin wrote:
>
> On Mon, Dec 11, 2023 at 03:26:46PM +0800, Jason Wang wrote:
> > > Try reducing the VHOST_NET_WEIGHT limit and see if that improves things
> > > any?
> >
> > Or a dirty hack like cond_resched() in translate_desc().
>
> what do you mean
On Mon, Dec 11, 2023 at 03:26:46PM +0800, Jason Wang wrote:
> > Try reducing the VHOST_NET_WEIGHT limit and see if that improves things any?
>
> Or a dirty hack like cond_resched() in translate_desc().
what do you mean, exactly?
--
MST
On Sat, Dec 9, 2023 at 6:42 PM Michael S. Tsirkin wrote:
>
> On Fri, Dec 08, 2023 at 12:41:38PM +0100, Tobias Huschle wrote:
> > On Fri, Dec 08, 2023 at 05:31:18AM -0500, Michael S. Tsirkin wrote:
> > > On Fri, Dec 08, 2023 at 10:24:16AM +0100, Tobias Huschle wrote:
> > > > On Thu, Dec 07, 2023 at
On Fri, Dec 08, 2023 at 12:41:38PM +0100, Tobias Huschle wrote:
> On Fri, Dec 08, 2023 at 05:31:18AM -0500, Michael S. Tsirkin wrote:
> > On Fri, Dec 08, 2023 at 10:24:16AM +0100, Tobias Huschle wrote:
> > > On Thu, Dec 07, 2023 at 01:48:40AM -0500, Michael S. Tsirkin wrote:
> > > > On Thu, Dec 07,
On Fri, Dec 08, 2023 at 05:31:18AM -0500, Michael S. Tsirkin wrote:
> On Fri, Dec 08, 2023 at 10:24:16AM +0100, Tobias Huschle wrote:
> > On Thu, Dec 07, 2023 at 01:48:40AM -0500, Michael S. Tsirkin wrote:
> > > On Thu, Dec 07, 2023 at 07:22:12AM +0100, Tobias Huschle wrote:
> > > > 3. vhost loopin
On Fri, Dec 08, 2023 at 10:24:16AM +0100, Tobias Huschle wrote:
> On Thu, Dec 07, 2023 at 01:48:40AM -0500, Michael S. Tsirkin wrote:
> > On Thu, Dec 07, 2023 at 07:22:12AM +0100, Tobias Huschle wrote:
> > > 3. vhost looping endlessly, waiting for kworker to be scheduled
> > >
> > > I dug a little
On Thu, Dec 07, 2023 at 01:48:40AM -0500, Michael S. Tsirkin wrote:
> On Thu, Dec 07, 2023 at 07:22:12AM +0100, Tobias Huschle wrote:
> > 3. vhost looping endlessly, waiting for kworker to be scheduled
> >
> > I dug a little deeper on what the vhost is doing. I'm not an expert on
> > virtio whatso
On Thu, Dec 07, 2023 at 07:22:12AM +0100, Tobias Huschle wrote:
> 3. vhost looping endlessly, waiting for kworker to be scheduled
>
> I dug a little deeper on what the vhost is doing. I'm not an expert on
> virtio whatsoever, so these are just educated guesses that maybe
> someone can verify/corre
On Tue, Nov 28, 2023 at 04:55:11PM +0800, Abel Wu wrote:
> On 11/27/23 9:56 PM, Tobias Huschle Wrote:
> > On Wed, Nov 22, 2023 at 11:00:16AM +0100, Peter Zijlstra wrote:
> > > On Tue, Nov 21, 2023 at 02:17:21PM +0100, Tobias Huschle wrote:
[...]
>
> What are the weights of the two entities?
>
Bo
On Tue, Nov 28, 2023 at 04:55:11PM +0800, Abel Wu wrote:
> On 11/27/23 9:56 PM, Tobias Huschle Wrote:
> > On Wed, Nov 22, 2023 at 11:00:16AM +0100, Peter Zijlstra wrote:
> > > On Tue, Nov 21, 2023 at 02:17:21PM +0100, Tobias Huschle wrote:
[...]
> > - At depth 4, the cgroup shows the observed vru
On 11/27/23 9:56 PM, Tobias Huschle Wrote:
On Wed, Nov 22, 2023 at 11:00:16AM +0100, Peter Zijlstra wrote:
On Tue, Nov 21, 2023 at 02:17:21PM +0100, Tobias Huschle wrote:
The below should also work for internal entities, but last time I poked
around with it I had some regressions elsewhere -- y
On Wed, Nov 22, 2023 at 11:00:16AM +0100, Peter Zijlstra wrote:
> On Tue, Nov 21, 2023 at 02:17:21PM +0100, Tobias Huschle wrote:
>
> The below should also work for internal entities, but last time I poked
> around with it I had some regressions elsewhere -- you know, fix one,
> wreck another type
On Tue, Nov 21, 2023 at 02:17:21PM +0100, Tobias Huschle wrote:
> We applied both suggested patch options and ran the test again, so
>
> sched/eevdf: Fix vruntime adjustment on reweight
> sched/fair: Update min_vruntime for reweight_entity() correctly
>
> and
>
> sched/eevdf: Delay dequeue
>
On Fri, Nov 17, 2023 at 09:07:55PM +0800, Abel Wu wrote:
> On 11/17/23 8:37 PM, Peter Zijlstra Wrote:
[...]
> > Ah, so if this is a cgroup issue, it might be worth trying this patch
> > that we have in tip/sched/urgent.
>
> And please also apply this fix:
> https://lore.kernel.org/all/2023111708
On 11/20/23 6:56 PM, Peter Zijlstra Wrote:
On Sat, Nov 18, 2023 at 01:14:32PM +0800, Abel Wu wrote:
Hi Peter, I'm a little confused here. As we adopt placement strategy #1
when PLACE_LAG is enabled, the lag of that entity needs to be preserved.
Given that the weight doesn't change, we have:
On Sat, Nov 18, 2023 at 01:14:32PM +0800, Abel Wu wrote:
> Hi Peter, I'm a little confused here. As we adopt placement strategy #1
> when PLACE_LAG is enabled, the lag of that entity needs to be preserved.
> Given that the weight doesn't change, we have:
>
> vl' = vl
>
> But in fact it is
On 11/17/23 5:23 PM, Peter Zijlstra Wrote:
Your email is pretty badly mangled by wrapping, please try and
reconfigure your MUA, esp. the trace and debug output is unreadable.
On Thu, Nov 16, 2023 at 07:58:18PM +0100, Tobias Huschle wrote:
The base scenario are two KVM guests running on an s39
On 11/17/23 8:37 PM, Peter Zijlstra Wrote:
On Fri, Nov 17, 2023 at 01:24:21PM +0100, Tobias Huschle wrote:
On Fri, Nov 17, 2023 at 10:23:18AM +0100, Peter Zijlstra wrote:
kworkers are typically not in cgroups and are part of the root cgroup,
but what's a vhost and where does it live?
The qe
Le 25/01/2023 à 20:11, Dan Williams a écrit :
Christophe JAILLET wrote:
strtobool() is the same as kstrtobool().
However, the latter is more used within the kernel.
In order to remove strtobool() and slightly simplify kstrtox.h, switch to
the other function name.
While at it, include the corre
On Mon, Apr 19, 2021 at 08:56:19PM +, Guido Kiener wrote:
> Hi all,
>
> The error is in usbtmc_interrupt(struct urb *urb) since five years. The
> status code EPROTO is not handled correctly.
> It's not a showstopper, but we should fix it and check the status code
> according to usbtmc_read_b
Hi all,
The error is in usbtmc_interrupt(struct urb *urb) since five years. The status
code EPROTO is not handled correctly.
It's not a showstopper, but we should fix it and check the status code
according to usbtmc_read_bulk_cb() or
usb_skeleton.c.
@Dave: Do you have time? Otherwise I can do it
On Mon, Apr 19, 2021 at 09:46:26AM +0800, 周传高 wrote:
>
> >On Sat, Apr 17, 2021 at 07:13:01AM -0700, zhouchuangao wrote:
> >> eg:
> >> In Android system, we usually and some processes to the whitelist.
> >> static task_t task_whitelist[] = {
> >>{"mdrt_thread", HUNG_TASK_WHITELIST},
> >>{"c
> Hi Dinghao,
> On Mon, Apr 12, 2021 at 03:31:54PM +0800, Dinghao Liu wrote:
> > There is a PM usage counter decrement after zynqmp_qspi_init_hw()
> > without any refcount increment, which leads to refcount leak.Add
> > a refcount increment to balance the refcount. Also set
> > auto_runtime_pm to r
Hi Jorgen,
Thanks for the detailed explanation and I agree with you. For the bind list,
my prototype is doing
something similar to that. I will double check it.
Hi Stefano,
I don't have other questions for now. Thanks.
Regards,
Jiang
On Tue, Apr 13, 2021 at 5:52 AM Stefano Garzarella wrote:
On Tue, Apr 13, 2021 at 08:54:55PM +0800, Kemeng Shi wrote:
> Yes. And NT stores should be better for copy_page especially copying a lot
> of pages as only partial memory of copied page will be access recently.
I thought "should be better" too last time when I measured rep; movs vs
NT stores but a
On Tue, Apr 13, 2021 at 08:56:30AM +0200, Christian Herber wrote:
> Hi Andrew,
>
> On 4/12/2021 6:52 PM, Andrew Lunn wrote:
> >
> > So what you are say is, you don't care if the IP is completely
> > different, it all goes in one driver. So lets put this driver into
> > nxp-tja11xx.c. And then we
+++ 周传高 [13/04/21 15:21 +0800]:
+++ zhouchuangao [30/03/21 05:07 -0700]:
It can be optimized at compile time.
Signed-off-by: zhouchuangao
Hi,
Could you please provide a more descriptive changelog? I.e., Is this
a fix for a cocinelle warning? What are the optimization(s)?
Thanks,
First,
Hi Andrew,
On 4/12/2021 6:52 PM, Andrew Lunn wrote:
So what you are say is, you don't care if the IP is completely
different, it all goes in one driver. So lets put this driver into
nxp-tja11xx.c. And then we avoid all the naming issues.
Andrew
As this seems to be a key question, let
On Mon, Apr 12, 2021 at 7:04 AM Stefano Garzarella wrote:
>
> Hi Jiang,
> thanks for re-starting the multi-transport support for dgram!
No problem.
> On Wed, Apr 07, 2021 at 11:25:36AM -0700, Jiang Wang . wrote:
> >On Wed, Apr 7, 2021 at 2:51 AM Jorgen Hansen wrote:
> >>
> >>
> >> > On 6 Apr 20
> On 21-04-07 13:22:26, Dinghao Liu wrote:
> > When cdns3_gadget_start() fails, a pairing PM usage counter
> > decrement is needed to keep the counter balanced.
> >
> > Signed-off-by: Dinghao Liu
> > ---
> > drivers/usb/cdns3/cdns3-gadget.c | 5 -
> > 1 file changed, 4 insertions(+), 1 delet
(trimmed off the batman/bpf Ccs)
On 2020-05-18 14:28, syzbot wrote:
syzbot has bisected this bug to:
commit 0d8dd67be013727ae57645ecd3ea2c36365d7da8
Author: Song Liu
Date: Wed Dec 6 22:45:14 2017 +
perf/headers: Sync new perf_event.h with the tools/include/uapi version
bisection l
> On 08/04/2021 08:11, Dinghao Liu wrote:
> > pm_runtime_get_sync() will increase the rumtime PM counter
> > even it returns an error. Thus a pairing decrement is needed
> > to prevent refcount leak. Fix this by replacing this API with
> > pm_runtime_resume_and_get(), which will not change the runt
> Hi Liu,
> Thanks for your patch.
>
> On Thu, Apr 08, 2021 at 05:08:27PM +0800, Dinghao Liu wrote:
> > When v4l2_subdev_call() fails, a pairing PM usage counter
> > decrement is needed to keep the counter balanced. It's the
> > same for the following error paths in case 'enable' is on.
> >
> > S
> Hi Dinghao,
>
> On 4/8/21 6:33 PM, Michal Simek wrote:
> > ++
> >
> > On 4/8/21 11:25 AM, Dinghao Liu wrote:
> >> When platform_get_irq() fails, a pairing PM usage counter
> >> increment is needed to keep the counter balanced. It's the
> >> same for the following error paths.
> >>
> >> Signed-of
> Hi Dinghao,
>
> On Wed, Apr 07, 2021 at 12:07:38PM +0800, Dinghao Liu wrote:
> > When mutex_lock_interruptible() fails, a pairing PM usage
> > counter decrement is needed to keep the counter balanced.
>
> Thank you for the patch.
>
> >
> > Signed-off-by: Dinghao Liu
> > ---
> > drivers/inpu
> On Wed, Apr 07, 2021 at 02:54:00PM +0800, Dinghao Liu wrote:
>
> > - pm_runtime_set_active(&client->dev);
> > - pm_runtime_set_autosuspend_delay(&client->dev, 1000);
> > - pm_runtime_use_autosuspend(&client->dev);
> > - pm_runtime_enable(&client->dev);
> > - pm_runtime_mark_last_busy(&
Hi Can Guo,
>
>Hi Daejun,
>
>On 2021-04-06 12:11, Daejun Park wrote:
>> Hi Can Guo,
>>
>>> +static ssize_t monitor_enable_store(struct device *dev,
>>> +struct device_attribute *attr,
>>> +const char *buf, size_t count)
>>>
> -原始邮件-
> 发件人: "Christoph Böhmwalder"
> 发送时间: 2021-04-01 21:01:20 (星期四)
> 收件人: "Lv Yunlong"
> 抄送: philipp.reis...@linbit.com, lars.ellenb...@linbit.com, ax...@kernel.dk,
> linux-bl...@vger.kernel.org, linux-kernel@vger.kernel.org,
> drbd-...@lists.linbit.com
> 主题: Re: [Drbd-dev] [PA
> -原始邮件-
> 发件人: lyl2...@mail.ustc.edu.cn
> 发送时间: 2021-04-01 23:13:58 (星期四)
> 收件人: "Christoph Böhmwalder"
> 抄送: philipp.reis...@linbit.com, lars.ellenb...@linbit.com, ax...@kernel.dk,
> linux-bl...@vger.kernel.org, linux-kernel@vger.kernel.org,
> drbd-..
1 - 100 of 1864 matches
Mail list logo
