On 4/3/24 12:46, Pavel Machek wrote:
> Hi!
>
>> Libcamera requires the cropping information for each mode, so
>> add this information to the driver.
>
>> @@ -116,6 +124,9 @@ struct imx258_mode {
>> u32 link_freq_index;
>> /* Default register values */
>> struct imx258_reg_list reg_
On 4/3/24 12:45, Pavel Machek wrote:
> Hi!
>
>> +/*
>> + * 4208x3120 @ 30 fps needs 1267Mbps/lane, 4 lanes.
>> + * To avoid further computation of clock settings, adopt the same per
>> + * lane data rate when using 2 lanes, thus allowing a maximum of 15fps.
>> + */
>> +static const struct imx258_r
On 4/5/24 08:11, Tommaso Merciai wrote:
> Hi Luis,
>
> On Fri, Apr 05, 2024 at 04:33:38AM -0600, Luis Garcia wrote:
>> On 4/4/24 00:46, Sakari Ailus wrote:
>>> On Wed, Apr 03, 2024 at 01:17:26PM -0600, Luigi311 wrote:
On 4/3/24 10:23, Sakari Ailus wrote:
> Hi Luis,
>
> On Wed, Apr
On 4/3/24 12:44, Pavel Machek wrote:
> Hi!
>
>> The device tree bindings define the relevant regulators for the
>> sensor, so update the driver to request the regulators and control
>> them at the appropriate times.
>
>> @@ -995,9 +1007,19 @@ static int imx258_power_on(struct device *dev)
>>
On Fri, 5 Apr 2024 13:02:30 +0200
Oleg Nesterov wrote:
> On 04/05, Jiri Olsa wrote:
> >
> > On Fri, Apr 05, 2024 at 10:22:03AM +0900, Masami Hiramatsu wrote:
> > >
> > > I think this expects setjmp/longjmp as below
> > >
> > > foo() { <- retprobe1
> > > setjmp()
> > > bar() { <- retprobe2
> >
On Thu, 4 Apr 2024 21:25:41 -0700
"Paul E. McKenney" wrote:
> On Fri, Apr 05, 2024 at 11:57:45AM +0900, Masami Hiramatsu wrote:
> > On Fri, 5 Apr 2024 10:23:24 +0900
> > Masami Hiramatsu (Google) wrote:
> >
> > > On Thu, 4 Apr 2024 10:43:14 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > > >
On Fri, Apr 5, 2024 at 7:03 AM Jonathan Cameron
wrote:
>
> On Fri, 5 Apr 2024 00:07:06 +
> "Ho-Ren (Jack) Chuang" wrote:
>
> > The current implementation treats emulated memory devices, such as
> > CXL1.1 type3 memory, as normal DRAM when they are emulated as normal memory
> > (E820_TYPE_RAM
Hello Honggyu,
On Fri, 5 Apr 2024 15:08:49 +0900 Honggyu Kim wrote:
> There was an RFC IDEA "DAMOS-based Tiered-Memory Management" previously
> posted at [1].
>
> It says there is no implementation of the demote/promote DAMOS action
> are made. This RFC is about its implementation for physica
On Fri, 5 Apr 2024 15:08:56 +0900 Honggyu Kim wrote:
> This patch adds "damon_migrate_{hot,cold}" under node specific vmstat
> counters at the following location.
>
> /sys/devices/system/node/node*/vmstat
>
> The counted values are accumulcated to the global vmstat so it also
> introduces th
On Fri, 5 Apr 2024 15:08:55 +0900 Honggyu Kim wrote:
> From: Hyeongtak Ji
>
> This patch introduces DAMOS_MIGRATE_HOT action, which is similar to
> DAMOS_MIGRATE_COLD, but it is targeted to migrate hot pages.
My understanding of our last discussion was that 'HOT/COLD' here is only for
priorit
On Fri, 5 Apr 2024 16:55:57 +0900 Hyeongtak Ji wrote:
> On Fri, 5 Apr 2024 15:08:54 +0900 Honggyu Kim wrote:
>
> ...snip...
>
> > +static unsigned long damon_pa_migrate_pages(struct list_head *folio_list,
> > + enum migration_mode mm,
> > +
On Fri, 5 Apr 2024 15:08:54 +0900 Honggyu Kim wrote:
> This patch introduces DAMOS_MIGRATE_COLD action, which is similar to
> DAMOS_PAGEOUT, but migrate folios to the given 'target_nid' in the sysfs
> instead of swapping them out.
>
> The 'target_nid' sysfs knob is created by this patch to info
On Fri, 5 Apr 2024 15:08:53 +0900 Honggyu Kim wrote:
> The current patch series introduces DAMON based migration across NUMA
> nodes so it'd be better to have a new migrate_reason in trace events.
>
> Signed-off-by: Honggyu Kim
Reviewed-by: SeongJae Park
Thanks,
SJ
> ---
> include/linux/
On Fri, 5 Apr 2024 15:08:51 +0900 Honggyu Kim wrote:
> The alloc_demote_folio can be used out of vmscan.c so it'd be better to
> remove static keyword from it.
>
> This function can also be used for both demotion and promotion so it'd
> be better to rename it from alloc_demote_folio to alloc_mi
On Fri, 5 Apr 2024 15:08:50 +0900 Honggyu Kim wrote:
> This is a preparation patch that introduces migration modes.
>
> The damon_pa_pageout is renamed to damon_pa_migrate and it receives an
> extra argument for migration_mode.
I personally think keeping damon_pa_pageout() as is and adding a n
On Fri, Apr 05, 2024 at 03:08:49PM +0900, Honggyu Kim wrote:
> There was an RFC IDEA "DAMOS-based Tiered-Memory Management" previously
> posted at [1].
>
> 1. YCSB zipfian distribution read only workload
> memory pressure with cold memory on node0 with 512GB of local DRAM.
> =+==
This commit replaces riscv's support for FTRACE_WITH_REGS with support
for FTRACE_WITH_ARGS. This is required for the ongoing effort to stop
relying on stop_machine() for RISCV's implementation of ftrace.
The main relevant benefit that this change will bring for the above
use-case is that now we d
On Fri, 5 Apr 2024 00:07:06 +
"Ho-Ren (Jack) Chuang" wrote:
> The current implementation treats emulated memory devices, such as
> CXL1.1 type3 memory, as normal DRAM when they are emulated as normal memory
> (E820_TYPE_RAM). However, these emulated devices have different
> characteristics t
On Wed, Apr 3, 2024 at 6:02 AM Masami Hiramatsu wrote:
>
> On Tue, 02 Apr 2024 15:02:41 +0200
> Björn Töpel wrote:
>
> > Puranjay Mohan writes:
> >
> > > This commit replaces riscv's support for FTRACE_WITH_REGS with support
> > > for FTRACE_WITH_ARGS. This is required for the ongoing effort to
On Fri, 5 Apr 2024 00:07:05 +
"Ho-Ren (Jack) Chuang" wrote:
> Since different memory devices require finding, allocating, and putting
> memory types, these common steps are abstracted in this patch,
> enhancing the scalability and conciseness of the code.
>
> Signed-off-by: Ho-Ren (Jack) Ch
With the demise of the .change_pte() MMU notifier callback, there is no
notification happening in set_pte_at_notify(). It is a synonym of
set_pte_at() and can be replaced with it.
Signed-off-by: Paolo Bonzini
---
include/linux/mmu_notifier.h | 2 --
kernel/events/uprobes.c | 5 ++---
mm/ks
The .change_pte() MMU notifier callback was intended as an optimization
and for this reason it was initially called without a surrounding
mmu_notifier_invalidate_range_{start,end}() pair. It was only ever
implemented by KVM (which was also the original user of MMU notifiers)
and the rules on when
The scope of set_pte_at_notify() has reduced more and more through the
years. Initially, it was meant for when the change to the PTE was
not bracketed by mmu_notifier_invalidate_range_{start,end}(). However,
that has not been so for over ten years. During all this period
the only implementation
The .change_pte() MMU notifier callback was intended as an
optimization. The original point of it was that KSM could tell KVM to flip
its secondary PTE to a new location without having to first zap it. At
the time there was also an .invalidate_page() callback; both of them were
*not* bracketed by c
The only user was kvm_mmu_notifier_change_pte(), which is now gone.
Signed-off-by: Paolo Bonzini
---
virt/kvm/kvm_main.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 2fcd9979752a..970111ad 100644
--- a/virt/kvm/kvm_
On 04/05, Jiri Olsa wrote:
>
> On Fri, Apr 05, 2024 at 10:22:03AM +0900, Masami Hiramatsu wrote:
> >
> > I think this expects setjmp/longjmp as below
> >
> > foo() { <- retprobe1
> > setjmp()
> > bar() { <- retprobe2
> > longjmp()
> > }
> > } <- return to trampoline
> >
> >
On 4/4/24 00:46, Sakari Ailus wrote:
> On Wed, Apr 03, 2024 at 01:17:26PM -0600, Luigi311 wrote:
>> On 4/3/24 10:23, Sakari Ailus wrote:
>>> Hi Luis,
>>>
>>> On Wed, Apr 03, 2024 at 09:03:50AM -0600, g...@luigi311.com wrote:
From: Luis Garcia
Use understandable macros instead of raw
Hi SeongJae,
On Tue, 26 Mar 2024 16:03:09 -0700 SeongJae Park wrote:
> On Mon, 25 Mar 2024 15:53:03 -0700 SeongJae Park wrote:
>
> > On Mon, 25 Mar 2024 21:01:04 +0900 Honggyu Kim wrote:
> [...]
> > > On Fri, 22 Mar 2024 09:32:23 -0700 SeongJae Park wrote:
> > > > On Fri, 22 Mar 2024 18:02:23
On Fri, Apr 05, 2024 at 10:22:03AM +0900, Masami Hiramatsu wrote:
> On Thu, 4 Apr 2024 18:11:09 +0200
> Oleg Nesterov wrote:
>
> > On 04/05, Masami Hiramatsu wrote:
> > >
> > > Can we make this syscall and uprobe behavior clearer? As you said, if
> > > the application use sigreturn or longjump, i
Hi Andi, hi everyone,
thank you for reviewing and waiting. I had a small personal hiatus over
Easter but now I am back. This series needs another cycle, so no need to
hurry. I will address some of the review comments but not all. The
conversion (and API improvements) are some bigger tasks, so
inco
On Fri, 5 Apr 2024 15:08:54 +0900 Honggyu Kim wrote:
...snip...
> +static unsigned long damon_pa_migrate_pages(struct list_head *folio_list,
> + enum migration_mode mm,
> + int target_nid)
> +{
> + int nid;
> +
31 matches
Mail list logo
