On 7/5/18 9:42 PM, Peter Zijlstra wrote:
> On Thu, Jul 05, 2018 at 09:21:15PM +0800, Xunlei Pang wrote:
>> On 7/5/18 6:46 PM, Peter Zijlstra wrote:
>>> On Wed, Jun 27, 2018 at 08:22:42PM +0800, Xunlei Pang wrote:
>>>> tick-based whole utime is utime_0, tick-bas
On 2020/7/7 下午2:59, Christopher Lameter wrote:
> On Thu, 2 Jul 2020, Xunlei Pang wrote:
>
>> This patch introduces two counters to maintain the actual number
>> of partial objects dynamically instead of iterating the partial
>> page lists with list_lock held.
>>
>
On 2020/7/7 下午11:23, Pekka Enberg wrote:
> Hi!
>
> (Sorry for the delay, I missed your response.)
>
> On Fri, Jul 3, 2020 at 12:38 PM xunlei wrote:
>>
>> On 2020/7/2 PM 7:59, Pekka Enberg wrote:
>>> On Thu, Jul 2, 2020 at 11:32 AM Xunlei Pang
&
On 2020/8/8 上午1:28, Pekka Enberg wrote:
> Hi Christopher,
>
> On Fri, 7 Aug 2020, Pekka Enberg wrote:
>>> I think we can just default to the counters. After all, if I
>>> understood correctly, we're talking about up to 100 ms time period
>>> with IRQs disabled when count_partial() is called. As th
On 2020/7/2 PM 7:59, Pekka Enberg wrote:
> On Thu, Jul 2, 2020 at 11:32 AM Xunlei Pang wrote:
>> The node list_lock in count_partial() spend long time iterating
>> in case of large amount of partial page lists, which can cause
>> thunder herd effect to the list_lock cont
On 2020/8/26 下午4:11, Michal Hocko wrote:
> On Wed 26-08-20 15:27:02, Xunlei Pang wrote:
>> We've met softlockup with "CONFIG_PREEMPT_NONE=y", when
>> the target memcg doesn't have any reclaimable memory.
>
> Do you have any scenario when this happens or is
On 2020/8/26 下午7:00, Michal Hocko wrote:
> On Wed 26-08-20 18:41:18, xunlei wrote:
>> On 2020/8/26 下午4:11, Michal Hocko wrote:
>>> On Wed 26-08-20 15:27:02, Xunlei Pang wrote:
>>>> We've met softlockup with "CONFIG_PREEMPT_NONE=y", when
>>>
On 2020/8/26 下午7:00, Michal Hocko wrote:
> On Wed 26-08-20 18:41:18, xunlei wrote:
>> On 2020/8/26 下午4:11, Michal Hocko wrote:
>>> On Wed 26-08-20 15:27:02, Xunlei Pang wrote:
>>>> We've met softlockup with "CONFIG_PREEMPT_NONE=y", when
>>>
On 2020/8/26 下午8:07, Michal Hocko wrote:
> On Wed 26-08-20 20:00:47, xunlei wrote:
>> On 2020/8/26 下午7:00, Michal Hocko wrote:
>>> On Wed 26-08-20 18:41:18, xunlei wrote:
>>>> On 2020/8/26 下午4:11, Michal Hocko wrote:
>>>>> On Wed 26-08-20 15:27:02, X
On 2020/8/26 下午8:48, Michal Hocko wrote:
> On Wed 26-08-20 20:21:39, xunlei wrote:
>> On 2020/8/26 下午8:07, Michal Hocko wrote:
>>> On Wed 26-08-20 20:00:47, xunlei wrote:
>>>> On 2020/8/26 下午7:00, Michal Hocko wrote:
>>>>> On Wed 26-08-20 18:41:18, xun
On 2020/8/26 下午9:26, Michal Hocko wrote:
> On Wed 26-08-20 21:16:28, xunlei wrote:
> [...]
>> oom_reaper also can't get scheduled because of 1-cpu, and the mutex
>> uses might_sleep() which is noop in case of "CONFIG_PREEMPT_VOLUNTARY is
>> not set" I mention
in_lock_irqsave(&n->list_lock, flags);
> list_for_each_entry(page, &n->partial, slab_list)
> x += get_count(page);
> spin_unlock_irqrestore(&n->list_lock, flags);
>
> It's counting the number of *objects*, but the counters are on
On 2020/8/20 下午10:02, Pekka Enberg wrote:
> On Mon, Aug 10, 2020 at 3:18 PM Xunlei Pang wrote:
>>
>> v1->v2:
>> - Improved changelog and variable naming for PATCH 1~2.
>> - PATCH3 adds per-cpu counter to avoid performance regression
>> in concurrent __slab
On 2020/8/24 PM9:38, Srikar Dronamraju wrote:
> * Xunlei Pang [2020-08-24 20:30:19]:
>
>> We've met problems that occasionally tasks with full cpumask
>> (e.g. by putting it into a cpuset or setting to full affinity)
>> were migrated to our isolated cpus in produc
On 2020/8/25 下午2:37, Jiang Biao wrote:
> On Mon, 24 Aug 2020 at 20:31, Xunlei Pang wrote:
>>
>> We've met problems that occasionally tasks with full cpumask
>> (e.g. by putting it into a cpuset or setting to full affinity)
>> were migrated to our isolate
On 2016/07/21 at 22:46, Juri Lelli wrote:
> On 21/07/16 15:36, Juri Lelli wrote:
>> On 21/07/16 15:21, Juri Lelli wrote:
>>> Hi,
>>>
>>> On 18/07/16 21:37, Xunlei Pang wrote:
>>>> On 2016/07/18 at 21:04, Juri Lelli wrote:
>>>>> On 1
the patch. You know sometimes lkml.org
>> does not work well.
> So, I'll try another archives when I post patch set next time.
Hi Hidehiro Kawai,
What's the status of this patch set, are you going to send an updated version?
Regards,
Xunlei
>>> To fix this problem, cal
PI donor) for setting up a new entity.
>
> This change removes the useless second parameter of setup_new_dl_entity().
> While we are at it we also optimize things further calling setup_new_dl_
> entity() only for already queued tasks, since (as pointed out by Xunlei)
> we already d
On 2016/08/24 at 16:20, Dave Young wrote:
> On 08/23/16 at 06:11pm, Yinghai Lu wrote:
>> On Wed, Aug 17, 2016 at 1:20 AM, Dave Young wrote:
>>> On 08/17/16 at 09:50am, Xunlei Pang wrote:
>>>> "/sys/kernel/kexec_crash_size" only handles crashk_res, it
>
On 06/22/2017 at 01:44 AM, Michael Holzheu wrote:
> Am Fri, 9 Jun 2017 10:17:05 +0800
> schrieb Xunlei Pang :
>
>> S390 KEXEC_NOTE_BYTES is not used by note_buf_t as before, which
>> is now defined as follows:
>> typedef u32 note_buf_t[CRASH_CORE_NOTE_BYTES/4
().
Moreover, now that "elfcorehdr=X" is left as decrypted, it needs to be remapped
to the
encrypted data.
Regards,
Xunlei
>
> Additionally, when shutting down all of the CPUs we need to be sure to
> flush the caches and then halt. This is needed when booting from a state
> wh
On 05/26/2017 at 10:49 AM, Dave Young wrote:
> Ccing Xunlei he is reading the patches see what need to be done for
> kdump. There should still be several places to handle to make kdump work.
>
> On 05/18/17 at 07:01pm, Borislav Petkov wrote:
>> On Tue, Apr 18, 2017 at 04:
From: Xunlei Pang
Since we are using cpuidle_driver::safe_state_index directly as the
target state index, it is better to add the sanity check at the point
of registering the driver.
Signed-off-by: Xunlei Pang
---
v2->v3:
Move the code to a new cpuidle_coupled_state_verify() depending
Hi Rafael,
On 3 September 2015 at 09:35, Rafael J. Wysocki wrote:
> On Monday, August 31, 2015 11:34:05 AM Xunlei Pang wrote:
>> From: Xunlei Pang
>>
>> Since we are using cpuidle_driver::safe_state_index directly as the
>> target state index, it is better to add th
On 6/21/18 1:01 AM, bseg...@google.com wrote:
> Xunlei Pang writes:
>
>> I noticed the group constantly got throttled even it consumed
>> low cpu usage, this caused some jitters on the response time
>> to some of our business containers enabling cpu quota.
>>
&g
On 6/21/18 4:08 PM, Peter Zijlstra wrote:
> On Thu, Jun 21, 2018 at 11:56:56AM +0800, Xunlei Pang wrote:
>>>> Fixes: 51f2176d74ac ("sched/fair: Fix unlocked reads of some
>>>> cfs_b->quota/period")
>>>> Cc: Ben Segall
>>>
>>&g
last parse in cputime_adjust(), and accumulate the
corresponding results calculated into prev_cputime. A new field
of task_cputime type is added in structure prev_cputime to record
previous task_cputime so that we can get the elapsed time deltas.
Signed-off-by: Xunlei Pang
---
include/linux/sched.h
On 6/22/18 6:35 PM, kbuild test robot wrote:
> Hi Xunlei,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on tip/sched/core]
> [also build test WARNING on v4.18-rc1 next-20180622]
> [if your patch is applied to the wrong git tree, ple
;s a problem, as expires_seq will get synced in
assign_cfs_rq_runtime().
Thanks,
Xunlei
>
> Fixes: 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift condition")
> Cc: Xunlei Pang
> Cc: Ben Segall
> Cc: Linus Torvalds
> Cc: Peter Zijlstra
> Cc: Thomas
On 7/31/18 1:55 AM, Cong Wang wrote:
> On Sun, Jul 29, 2018 at 10:29 PM Xunlei Pang wrote:
>>
>> Hi Cong,
>>
>> On 7/28/18 8:24 AM, Cong Wang wrote:
>>> Each time we sync cfs_rq->runtime_expires with cfs_b->runtime_expires,
>>> we should sync i
On 8/1/18 4:55 AM, Cong Wang wrote:
> On Tue, Jul 31, 2018 at 10:13 AM wrote:
>>
>> Xunlei Pang writes:
>>
>>> On 7/31/18 1:55 AM, Cong Wang wrote:
>>>> On Sun, Jul 29, 2018 at 10:29 PM Xunlei Pang
>>>> wrote:
>>>>>
>&g
On 7/23/18 5:21 PM, Peter Zijlstra wrote:
> On Tue, Jul 17, 2018 at 12:08:36PM +0800, Xunlei Pang wrote:
>> The trace data corresponds to the last sample period:
>> trace entry 1:
>> cat-20755 [022] d... 1370.106496: cputime_adjust: task
>> tick-bas
if positive after throttling.
Fixes: df8eac8cafce ("sched/deadline: Throttle a constrained deadline task
activated after the deadline)
Acked-by: Daniel Bristot de Oliveira
Signed-off-by: Xunlei Pang
---
kernel/sched/deadline.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kern
errun_block: 0
dl.nr_underrun_yield: 0
Very large "dl.nr_underrun_sched" hints it's very likely that
there is some underlying scheduling issue.
Note that we don't use CONFIG_SCHED_DEBUG as the accounting
added has little overhead(also
case of missed
deadlines")
Cc: Luca Abeni
Signed-off-by: Xunlei Pang
---
kernel/sched/deadline.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index d3d291e..5691149 100644
--- a/kernel/sched/deadline.c
+++ b/ke
On 05/11/2017 at 09:38 AM, Xunlei Pang wrote:
> On 05/10/2017 at 09:36 PM, Steven Rostedt wrote:
>> On Wed, 10 May 2017 21:03:37 +0800
>> Xunlei Pang wrote:
>>
>>> When a contrained task is throttled by dl_check_constrained_dl(),
>>> it may carry the remai
On 05/12/2017 at 01:57 PM, luca abeni wrote:
> Hi again,
>
> (sorry for the previous email; I replied from gmail and I did not
> realize I was sending it in html).
>
>
> On Fri, 12 May 2017 11:32:08 +0800
> Xunlei Pang wrote:
>
>> dl_runtime_exceeded() only
On 05/12/2017 at 03:01 PM, luca abeni wrote:
> Hi,
>
> On Fri, 12 May 2017 14:53:33 +0800
> Xunlei Pang wrote:
>
>> On 05/12/2017 at 01:57 PM, luca abeni wrote:
>>> Hi again,
>>>
>>> (sorry for the previous email; I replied from gmail an
On 05/13/2017 at 04:58 AM, luca abeni wrote:
> On Fri, 12 May 2017 15:19:55 +0800
> Xunlei Pang wrote:
> [...]
>>>> "As seen, enforcing that the total utilization is smaller than M
>>>> does not guarantee that global EDF schedules the tasks without
>
hen/Andrew,
Sorry for the trouble.
The following patch will fix it, do you want to me to send it out separately?
or help merge it into
fc7d2b44367f ("powerpc/fadump: use the correct VMCOREINFO_NOTE_SIZE for phdr")
directly?
Thanks,
Xunlei
===
Fr
On 05/12/2017 at 11:32 AM, Xunlei Pang wrote:
> When a contrained task is throttled by dl_check_constrained_dl(),
> it may carry the remaining positive runtime, as a result when
> dl_task_timer() fires and calls replenish_dl_entity(), it will
> not be replenished correctly due to
MCOREINFO_BYTES.
Andrew will help merge it into commit fc7d2b44367f ("powerpc/fadump:
use the correct VMCOREINFO_NOTE_SIZE for phdr") before sending it to
stable.
Signed-off-by: Xunlei Pang
---
kernel/crash_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel
Hi Roman,
On 2018/12/4 AM 2:00, Roman Gushchin wrote:
> On Mon, Dec 03, 2018 at 04:01:17PM +0800, Xunlei Pang wrote:
>> When usage exceeds min, min usage should be min other than 0.
>> Apply the same for low.
>>
>> Signed-off-by: Xunlei Pang
>> ---
>> mm
When usage exceeds min, min usage should be min other than 0.
Apply the same for low.
Signed-off-by: Xunlei Pang
---
mm/page_counter.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/mm/page_counter.c b/mm/page_counter.c
index de31470655f6..75d53f15f040 100644
igned-off-by: Xunlei Pang
---
mm/vmscan.c | 8
1 file changed, 8 insertions(+)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 62ac0c488624..3d412eb91f73 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3531,6 +3531,7 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int
classzon
this part of usages to be reclaimed.
Signed-off-by: Xunlei Pang
---
include/linux/memcontrol.h | 7 +--
mm/memcontrol.c| 9 +++--
mm/vmscan.c| 17 +++--
3 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/include/linux/memcontrol.h b
On 2018/12/3 下午7:54, Michal Hocko wrote:
> On Mon 03-12-18 16:01:17, Xunlei Pang wrote:
>> When usage exceeds min, min usage should be min other than 0.
>> Apply the same for low.
>
> Why? What is the actual problem.
children_min_usage tracks the total children usages un
On 2018/12/3 下午7:56, Michal Hocko wrote:
> On Mon 03-12-18 16:01:18, Xunlei Pang wrote:
>> There may be cgroup memory overcommitment, it will become
>> even common in the future.
>>
>> Let's enable kswapd to reclaim low-protected memory in case
>> of memory p
On 2018/12/4 AM 1:22, Michal Hocko wrote:
> On Mon 03-12-18 23:20:31, Xunlei Pang wrote:
>> On 2018/12/3 下午7:56, Michal Hocko wrote:
>>> On Mon 03-12-18 16:01:18, Xunlei Pang wrote:
>>>> There may be cgroup memory overcommitment, it will become
>>>>
On 2018/12/3 PM 7:57, Michal Hocko wrote:
> On Mon 03-12-18 16:01:19, Xunlei Pang wrote:
>> When memcgs get reclaimed after its usage exceeds min, some
>> usages below the min may also be reclaimed in the current
>> implementation, the amount is considerably large dur
On 2018/12/4 PM 3:25, Michal Hocko wrote:
> On Tue 04-12-18 10:40:29, Xunlei Pang wrote:
>> On 2018/12/4 AM 1:22, Michal Hocko wrote:
>>> On Mon 03-12-18 23:20:31, Xunlei Pang wrote:
>>>> On 2018/12/3 下午7:56, Michal Hocko wrote:
>>>>> On Mon 03-12-18
Hi Peter,
On 7/5/18 9:21 PM, Xunlei Pang wrote:
> On 7/5/18 6:46 PM, Peter Zijlstra wrote:
>> On Wed, Jun 27, 2018 at 08:22:42PM +0800, Xunlei Pang wrote:
>>> tick-based whole utime is utime_0, tick-based whole stime
>>> is stime_0, scheduler time is rtime_0.
>>
time type field is added in prev_cputime to record
previous task_cputime so that we can get the elapsed times as the accurate
ratio.
Signed-off-by: Xunlei Pang
---
v1->v2:
- Rewrite the changelog.
include/linux/sched.h | 34
include/linux/sched/cputi
Hi Peter,
On 7/9/18 6:48 PM, Peter Zijlstra wrote:
> On Mon, Jul 09, 2018 at 01:52:38PM +0800, Xunlei Pang wrote:
>> Please see the enclosure for the reproducer cputime_adjust.tgz
>
> No, I'm not going to reverse engineer something if you cannot even
> explain what the pr
On 6/22/18 3:15 PM, Xunlei Pang wrote:
> We use per-cgroup cpu usage statistics similar to "cgroup rstat",
> and encountered a problem that user and sys usages are wrongly
> split sometimes.
>
> Run tasks with some random run-sleep pattern for a long time, and
> when t
On 6/26/18 11:49 PM, Peter Zijlstra wrote:
> On Tue, Jun 26, 2018 at 08:19:49PM +0800, Xunlei Pang wrote:
>> On 6/22/18 3:15 PM, Xunlei Pang wrote:
>>> We use per-cgroup cpu usage statistics similar to "cgroup rstat",
>>> and encountered a problem that user
is re-armed.
The global expiration should be advanced accordingly when the
bandwidth period timer is restarted.
Signed-off-by: Xunlei Pang
---
kernel/sched/fair.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 9f
following patch.
Fixes: 51f2176d74ac ("sched/fair: Fix unlocked reads of some
cfs_b->quota/period")
Cc: Ben Segall
Signed-off-by: Xunlei Pang
---
kernel/sched/fair.c | 14 --
kernel/sched/sched.h | 6 --
2 files changed, 12 insertions(+), 8 deletions(-)
diff --gi
On 6/19/18 2:44 AM, bseg...@google.com wrote:
> Xunlei Pang writes:
>
>> The current condition to judge clock drift in expire_cfs_rq_runtime()
>> is wrong, the two runtime_expires are actually the same when clock
>> drift happens, so this condtion can never hit
On 6/19/18 2:58 AM, bseg...@google.com wrote:
> Xunlei Pang writes:
>
>> I noticed the group frequently got throttled even it consumed
>> low cpu usage, this caused some jitters on the response time
>> to some of our business containers enabling cpu quota.
>>
On 6/19/18 12:36 PM, Cong Wang wrote:
> On Mon, Jun 18, 2018 at 2:16 AM, Xunlei Pang wrote:
>> I noticed the group frequently got throttled even it consumed
>> low cpu usage, this caused some jitters on the response time
>> to some of our business containers enabling cpu q
On 6/20/18 1:49 AM, bseg...@google.com wrote:
> Xunlei Pang writes:
>
>> On 6/19/18 2:58 AM, bseg...@google.com wrote:
>>> Xunlei Pang writes:
>>>
>>>> I noticed the group frequently got throttled even it consumed
>>>> low cpu usage, this ca
date the global expiration in start_cfs_bandwidth() to avoid frequent
expire_cfs_rq_runtime() calls once a new period begins.
Signed-off-by: Xunlei Pang
---
kernel/sched/fair.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair
76d74ac ("sched/fair: Fix unlocked reads of some
cfs_b->quota/period")
Cc: Ben Segall
Signed-off-by: Xunlei Pang
---
kernel/sched/fair.c | 14 --
kernel/sched/sched.h | 6 --
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/kernel/sched/
On 6/20/18 2:06 PM, Xunlei Pang wrote:
> On 6/20/18 1:49 AM, bseg...@google.com wrote:
>> Xunlei Pang writes:
>>
>>> On 6/19/18 2:58 AM, bseg...@google.com wrote:
>>>> Xunlei Pang writes:
>>>>
>>>>> I noticed the group frequently
On 7/2/18 11:21 PM, Tejun Heo wrote:
> Hello, Peter.
>
> On Tue, Jun 26, 2018 at 05:49:08PM +0200, Peter Zijlstra wrote:
>> Well, no, because the Changelog is incomprehensible and the patch
>> doesn't really have useful comments, so I'll have to reverse engineer
>> the entire thing, and I've just
On 7/5/18 6:46 PM, Peter Zijlstra wrote:
> On Wed, Jun 27, 2018 at 08:22:42PM +0800, Xunlei Pang wrote:
>> tick-based whole utime is utime_0, tick-based whole stime
>> is stime_0, scheduler time is rtime_0.
>
>> For a long time, the process runs mainly in userspace wi
On 7/17/18 1:41 AM, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
>> On Sun, Jul 15, 2018 at 04:36:17PM -0700, tip-bot for Xunlei Pang wrote:
>>> Commit-ID: 8d4c00dc38a8aa30dae8402955e55e7b34e74bc8
>>> Gitweb:
>>> https://git.kernel.org/ti
ll disfunctional due to
timer2 with the earliest expires in the timerqueue.
So, rtc drivers must set this flag if they don't support UIE.
Signed-off-by: Xunlei Pang
---
drivers/rtc/rtc-ab8500.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/rtc/rtc-ab8500.c b/drivers/rtc/rtc-ab8
pires time, so the alarm irq will never be programmed.
When such failures happen, this patch will retry __rtc_set_alarm(), if
still can't program the alarm time, it will remove current rtc_timer from
timerqueue and fetch next one, thus preventing it from affecting other
rtc timers.
Signed-off-
Hi Thomas,
On 23 January 2015 at 05:07, Thomas Gleixner wrote:
> On Thu, 22 Jan 2015, Xunlei Pang wrote:
>> When doing timekeeping_resume(), if the nonstop clocksource
>> wraps back, "cycle_delta" will miss the wrap time.
>>
>> It's hard to de
On 23 January 2015 at 02:30, John Stultz wrote:
> On Thu, Jan 22, 2015 at 4:01 AM, Xunlei Pang wrote:
>> If a system does not provide a persistent_clock(), the time
>> will be updated on resume by rtc_resume(). With the addition
>> of the non-stop clocksources for suspend
Hi Peter, Juri,
Could you please give some comments on these 5 patches?
Thanks for your time.
Regards,
Xunlei
On 19 January 2015 at 12:49, Xunlei Pang wrote:
> Currently, cpudl::free_cpus contains all cpus during init, see
> cpudl_init(). When calling cpudl_find(), we have to add rd->
From: Xunlei Pang
rtc_class_ops's set_alarm() shouldn't deal with the alarm date,
as this is handled in the rtc core.
See rtc_dev_ioctl()'s RTC_ALM_SET and RTC_WKALM_SET cases.
Signed-off-by: Xunlei Pang
---
drivers/rtc/rtc-mxc.c | 22 --
1 file change
From: Xunlei Pang
Change alpha_rtc_set_mmss() and remote_set_mmss() to use
rtc_class_ops's set_mmss64().
Signed-off-by: Xunlei Pang
---
arch/alpha/kernel/rtc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/alpha/kernel/rtc.c b/arch/alpha/kernel/rtc.c
From: Xunlei Pang
As part of addressing "y2038 problem" for in-kernel uses, this
patch adds safe get_seconds64() using time64_t.
After this patch, get_seconds() is deprecated and all its call sites
will be fixed using get_seconds64(), after that it can be removed.
Signed-off-by: X
From: Xunlei Pang
This driver has a number of y2038/y2106 issues.
This patch resolves them by:
- Repalce get_seconds() with get_seconds64()
- Replace rtc_time_to_tm() with rtc_time64_to_tm()
- Change test_rtc_set_mmss() to use rtc_class_ops's set_mmss64()
After this patch, this driver s
From: Xunlei Pang
This driver has a number of y2038/y2106 issues.
This patch resolves them by:
- Replace rtc_time_to_tm() with rtc_time64_to_tm()
- Replace rtc_tm_to_time() with rtc_tm_to_time64()
- Change mxc_rtc_set_mmss() to use rtc_class_ops's set_mmss64()
After this patch, the d
From: Xunlei Pang
This patch series relies on a former patchset[1], it provides y2038/y2106
safe rtc_class_ops.set_mmss64(), and converts some possible users of set_mmss()
to use set_mmss64(), in the hope that making these users(i.e. rtc drivers)
y2038/y2106 safe.
The first version of this
From: Xunlei Pang
Currently the rtc_class_op's set_mmss() function takes a 32bit second
value (on 32bit systems), which is problematic for dates past y2038.
This patch provides a safe version named set_mmss64() using y2038 safe
time64_t.
After this patch, set_mmss() is deprecated and al
From: Xunlei Pang
We want to convert mxc_rtc_set_mmss() to use rtc_class_ops's set_mmss64(),
but it uses get_alarm_or_time()/set_alarm_or_time() internal interfaces
which are y2038 unsafe.
So here as a separate patch, it converts these two internal interfaces
of "mxc" to use s
From: Xunlei Pang
This driver has a number of y2038/y2106 issues.
This patch resolves them by:
- Replace rtc_tm_to_time() with rtc_tm_to_time64()
- Replace rtc_time_to_tm() with rtc_time64_to_tm()
- Change ab3100_rtc_set_mmss() to use rtc_class_ops's set_mmss64()
After this patch, the d
From: Xunlei Pang
This driver has a number of y2038/y2106 issues.
This patch resolves them by:
- Replace rtc_time_to_tm() with rtc_time64_to_tm()
- Change mc13xxx_rtc_set_mmss() to use rtc_class_ops's set_mmss64()
After this patch, the driver should not have any remaining
y2038/y2106 i
On 14 January 2015 at 04:42, Thomas Gleixner wrote:
> On Tue, 13 Jan 2015, Xunlei Pang wrote:
>
>> From: Xunlei Pang
>>
>> As part of addressing "y2038 problem" for in-kernel uses, this
>> patch adds safe get_seconds64() using time64_t.
>>
>> A
On 14 January 2015 at 00:19, Alessandro Zummo wrote:
> On Tue, 13 Jan 2015 23:44:51 +0800
> Xunlei Pang wrote:
>
>> This patch resolves them by:
>> - Repalce get_seconds() with get_seconds64()
>> - Replace rtc_time_to_tm() with rtc_time64_to_tm()
>> -
Cc Uwe Kleine-Koenig
On 13 January 2015 at 23:44, Xunlei Pang wrote:
> From: Xunlei Pang
>
> This driver has a number of y2038/y2106 issues.
>
> This patch resolves them by:
> - Replace rtc_time_to_tm() with rtc_time64_to_tm()
> - Change mc13xxx_rtc_set_mmss() to use rtc_c
Cc Fabio Estevam
On 13 January 2015 at 23:44, Xunlei Pang wrote:
> From: Xunlei Pang
>
> rtc_class_ops's set_alarm() shouldn't deal with the alarm date,
> as this is handled in the rtc core.
>
> See rtc_dev_ioctl()'s RTC_ALM_SET and RTC_WKALM_SET case
On 14 January 2015 at 23:03, Alessandro Zummo wrote:
> On Wed, 14 Jan 2015 22:56:15 +0800
> Xunlei Pang wrote:
>
>> We want to do away with set_mmss() eventually, time64 is the final version,
>> so I think this would be ok.
>
> We'll get rid of set_mmss() from th
On 14 January 2015 at 23:39, Alessandro Zummo wrote:
> On Wed, 14 Jan 2015 23:26:37 +0800
> Xunlei Pang wrote:
>
>> But on the other hand, we will have no test for set_mmss64(),
>> because adding the set_mmss64() will make set_mmss() dysfunctional.
>
> add a modu
t use of percpu local_cpu_mask
to save an extra mask allocation, so always passing a non-NULL
lowest_mask to cpupri_find().
Signed-off-by: Xunlei Pang
---
kernel/sched/core.c | 2 ++
kernel/sched/cpupri.c | 22 +-
kernel/sched/cpupri.h | 1 +
kernel/sched/rt.c | 9
onto a dying cpu) which
rq_offline_dl() can't handle timely, then it can be handled
through _cpu_down()->...->multi_cpu_stop()->migration_call()
->migrate_tasks(), preventing the task from hanging on the
dead cpu.
Signed-off-by: Xunlei Pang
---
kernel/sched/cpudeadline.c | 3 +--
In check_preempt_equal_dl(), cpudl_find() is called with a NULL
later_mask, thus cpudl_find() here doesn't check cpudl::free_cpus
at all.
This patch takles this issue by always passing a non-NULL later_mask
to cpudl_find(), thereby fixing this issue.
Signed-off-by: Xunlei Pang
---
kernel/
e interation of
sched_domain() in passing.
Signed-off-by: Xunlei Pang
---
kernel/sched/rt.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index d28cfa4..e6a42e6 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1535,6 +1
_rq().
This patch adds cpudl_set_freecpu() and cpudl_clear_freecpu() for
changing cpudl::free_cpus when doing rq_online_dl()/rq_offline_dl(),
so we can avoid the rd->span operation when calling cpudl_find()
in find_later_rq().
Signed-off-by: Xunlei Pang
---
kernel/sched/cpudeadline.
goto free_rto_mask;
>> > +
>> > + rd->cpupri.cpudl = &rd->cpudl;
>>
>> This is disgusting though; it breaks the cpuri abstraction. Why not pass
>> in the mask in the one place you actually need it?
>
> Yeah, probably should change cpupri_init(
Hi Peter,
On 28 January 2015 at 00:47, Peter Zijlstra wrote:
> On Mon, Jan 19, 2015 at 04:49:38AM +0000, Xunlei Pang wrote:
>> In check_preempt_equal_dl(), cpudl_find() is called with a NULL
>> later_mask, thus cpudl_find() here doesn't check cpudl::free_cpus
>> at al
From: Xunlei Pang
isl1208_i2c_set_alarm() uses deprecated rtc_tm_to_time(),
which will overflow in year 2106 on 32-bit machines.
This patch solves this by:
- Replacing rtc_tm_to_time() with rtc_tm_to_time64()
Cc: Herbert Valerio Riedel
Signed-off-by: Xunlei Pang
---
drivers/rtc/rtc-isl1208
From: Xunlei Pang
pcf8563_rtc_set_alarm() uses deprecated rtc_tm_to_time()
and rtc_time_to_tm(), which will overflow in year 2106
on 32-bit machines.
This patch solves this by:
- Replacing rtc_time_to_tm() with rtc_time64_to_tm()
- Replacing rtc_tm_to_time() with rtc_tm_to_time64()
Signed
From: Xunlei Pang
sunxi_rtc_setalarm() uses deprecated rtc_tm_to_time(),
which will overflow in year 2106 on 32-bit machines.
This patch solves this by:
- Replacing rtc_tm_to_time() with rtc_tm_to_time64()
Also remove the unnecessary initial zeroing of some
local variables in
From: Xunlei Pang
The driver uses deprecated rtc_tm_to_time() and rtc_time_to_tm(),
which will overflow in year 2106 on 32-bit machines.
This patch solves this by:
- Replacing rtc_tm_to_time() with rtc_tm_to_time64()
- Replacing rtc_time_to_tm() with rtc_time64_to_tm()
Cc: Russell King
1 - 100 of 584 matches
Mail list logo
