gt;nr_running == 1) {
> + /* Avoid tasks exiting pulling parents to new nodes */
Semi-confusing wording (WTH are "pulling parents"? :) - possibly better
variant?:
Avoid having exiting tasks pull their parents to new nodes
Good catch, it seems.
HTH,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
gt;nr_running == 1) {
> + /* Avoid tasks exiting pulling parents to new nodes */
Semi-confusing wording (WTH are "pulling parents"? :) - possibly better
variant?:
Avoid having exiting tasks pull their parents to new nodes
Good catch, it seems.
HTH,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
On Thu, Jun 29, 2017 at 08:26:20AM +0200, Andreas Mohr wrote:
> On Wed, Jun 28, 2017 at 02:19:25PM +0200, Petr Mladek wrote:
> > On Wed 2017-05-31 16:22:33, Sergey Senozhatsky wrote:
> > > so I try to minimize the negative impact of RT prio here. printk_kthread
> > > is
On Thu, Jun 29, 2017 at 08:26:20AM +0200, Andreas Mohr wrote:
> On Wed, Jun 28, 2017 at 02:19:25PM +0200, Petr Mladek wrote:
> > On Wed 2017-05-31 16:22:33, Sergey Senozhatsky wrote:
> > > so I try to minimize the negative impact of RT prio here. printk_kthread
> > > is
queue payload
(insertion submission of further elements into this queue
must still be possible at any time
without (excessive) blocking, though, of course).
while (can_continue_dumping)
{
payload_mutex_begin();
element = grab_element();
payload_mutex_end();
dump_element(element);
}
payload_mutex_begin();
queue_element(element);
payload_mutex_end();
HTH,
Andreas Mohr
queue payload
(insertion submission of further elements into this queue
must still be possible at any time
without (excessive) blocking, though, of course).
while (can_continue_dumping)
{
payload_mutex_begin();
element = grab_element();
payload_mutex_end();
dump_element(element);
}
payload_mutex_begin();
queue_element(element);
payload_mutex_end();
HTH,
Andreas Mohr
ore special" thread worker context)
should merely be *one* user of these printk queue servicing APIs.
And those servicing APIs should simply be invocable by anyone
who would want to take part in
getting the printk queue load properly serviced,
without any special handwaving.
[I can easily make all those "easy" wishlist requests -
I did not have to painfully design all that stuff ;-)]
Andreas Mohr
ore special" thread worker context)
should merely be *one* user of these printk queue servicing APIs.
And those servicing APIs should simply be invocable by anyone
who would want to take part in
getting the printk queue load properly serviced,
without any special handwaving.
[I can easily make all those "easy" wishlist requests -
I did not have to painfully design all that stuff ;-)]
Andreas Mohr
uge of small
> + * bios in case of mkfs.
"huge of small bios in case" - -ENOPARSE.
"huge numbers of"?
"huge or small"?
HTH,
Andreas Mohr
uge of small
> + * bios in case of mkfs.
"huge of small bios in case" - -ENOPARSE.
"huge numbers of"?
"huge or small"?
HTH,
Andreas Mohr
itely isolated from
awkward "implementation aspects" necessity which is currently poisoning user
code implementation).
Put differently,
handling preferrably ought to get consistently adapted (i.e., switched)
*centrally*,
rather than
requiring weird helpers (printk_emergency_X(
ation aspects" necessity which is currently poisoning user
code implementation).
Put differently,
handling preferrably ought to get consistently adapted (i.e., switched)
*centrally*,
rather than
requiring weird helpers (printk_emergency_X()) at all user code sites.
...or so goes the theory.
(quite possibly such thoughts may hit roadblocks e.g. due to locking/atomicity
issues)
HTH,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
ecision here
again simply is due to
the very frequently observable case of
saying "thou shan't do this" without then also
giving some tried-and-true *reason(s)* for such advice.
("ERROR: Macros with complex values should be enclosed in parentheses")
HTH,
Andreas Mohr
ecision here
again simply is due to
the very frequently observable case of
saying "thou shan't do this" without then also
giving some tried-and-true *reason(s)* for such advice.
("ERROR: Macros with complex values should be enclosed in parentheses")
HTH,
Andreas Mohr
On Tue, Oct 11, 2016 at 01:02:10PM -0700, Doug Anderson wrote:
> Andreas,
>
> On Tue, Oct 11, 2016 at 12:30 PM, Andreas Mohr <a...@lisas.de> wrote:
> > This loop implementation relies on negative kmin (result of ktime_sub())
> > getting internally handled by schedu
On Tue, Oct 11, 2016 at 01:02:10PM -0700, Doug Anderson wrote:
> Andreas,
>
> On Tue, Oct 11, 2016 at 12:30 PM, Andreas Mohr wrote:
> > This loop implementation relies on negative kmin (result of ktime_sub())
> > getting internally handled by schedule_hrtimeout_
annoyingly extra calculation via ktime_before() call
should simply be removed completely.
Which would be a good step since it would centralize protocol behaviour
within the inner handling of the helper
rather than bloating user-side instruction cache footprint.
?
Thanks,
Andreas Mohr
annoyingly extra calculation via ktime_before() call
should simply be removed completely.
Which would be a good step since it would centralize protocol behaviour
within the inner handling of the helper
rather than bloating user-side instruction cache footprint.
?
Thanks,
Andreas Mohr
ose users then surely wouldn't want to experience a behaviour
where the delay may be ended at any time,
however short that may end up being.
A related topic probably is
premature wakeups (e.g. signal-induced) of select() etc. protocol.
Greetings,
Andreas Mohr
ose users then surely wouldn't want to experience a behaviour
where the delay may be ended at any time,
however short that may end up being.
A related topic probably is
premature wakeups (e.g. signal-induced) of select() etc. protocol.
Greetings,
Andreas Mohr
type of input data is rather irrelevant -
all that matters is how you want to treat things in your *inner handling* -
and if that happens to be ktime-based
(as is usually - if not pretty much always - the case within kernel code),
then it ought to be that way,
*consistently* (to avoid conversion transition overhead).
Andreas Mohr
type of input data is rather irrelevant -
all that matters is how you want to treat things in your *inner handling* -
and if that happens to be ktime-based
(as is usually - if not pretty much always - the case within kernel code),
then it ought to be that way,
*consistently* (to avoid conversion transition overhead).
Andreas Mohr
t; time,
thereby bogusly accumulating scheduling-based delays
with each new loop iteration etc.
(i.e., things should still be based on hard, precise termination according to
an *initially* calculated, *absolute*, *minimum* expiry time).
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
ng scheduling-based delays
with each new loop iteration etc.
(i.e., things should still be based on hard, precise termination according to
an *initially* calculated, *absolute*, *minimum* expiry time).
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
n-likely cases
which will contribute towards
non-predictable, non-deterministic latency behaviour of
a code path
(think RT requirements)
Thanks,
Andreas Mohr
n-likely cases
which will contribute towards
non-predictable, non-deterministic latency behaviour of
a code path
(think RT requirements)
Thanks,
Andreas Mohr
On Tue, Sep 06, 2016 at 10:23:28AM +0200, Peter Zijlstra wrote:
> On Tue, Sep 06, 2016 at 03:58:00AM +0200, Andreas Mohr wrote:
> > Hi,
> >
> > [no properly binding reference via In-Reply-To: available thus manually
> > re-creating, sorry]
> >
>
On Tue, Sep 06, 2016 at 10:23:28AM +0200, Peter Zijlstra wrote:
> On Tue, Sep 06, 2016 at 03:58:00AM +0200, Andreas Mohr wrote:
> > Hi,
> >
> > [no properly binding reference via In-Reply-To: available thus manually
> > re-creating, sorry]
> >
>
easy to follow,
thus I'm not fully sure)
Thanks for working in this important area!
HTH,
Andreas Mohr
easy to follow,
thus I'm not fully sure)
Thanks for working in this important area!
HTH,
Andreas Mohr
On Tue, Sep 06, 2016 at 02:26:06PM +0800, Baolin Wang wrote:
> On 6 September 2016 at 12:34, Andreas Mohr <a...@lisas.de> wrote:
> >> - to = from + nr;
> >> -
> >> - if (to <= from)
> >> - return -EINVAL;
> >
> > Hmm,
On Tue, Sep 06, 2016 at 02:26:06PM +0800, Baolin Wang wrote:
> On 6 September 2016 at 12:34, Andreas Mohr wrote:
> >> - to = from + nr;
> >> -
> >> - if (to <= from)
> >> - return -EINVAL;
> >
> > Hmm, this is swallow
re inclusive */
> + to -= 1;
> }
>
> - if (nr == 0)
> - return 0;
> -
> - to = from + nr;
> -
> - if (to <= from)
> - return -EINVAL;
Hmm, this is swallowing -EINVAL behaviour
i.e., now possibly violating protocol?
(this may easily be ok - haven't done an extensive review -
but since the commit has that characteristic change,
the commit message should contain that detail)
Thanks for the cleanup work & HTH,
Andreas Mohr
> - if (nr == 0)
> - return 0;
> -
> - to = from + nr;
> -
> - if (to <= from)
> - return -EINVAL;
Hmm, this is swallowing -EINVAL behaviour
i.e., now possibly violating protocol?
(this may easily be ok - haven't done an extensive review -
but since the commit has that characteristic change,
the commit message should contain that detail)
Thanks for the cleanup work & HTH,
Andreas Mohr
y large amount of LOC extensions
which put certain amounts of stress on
code implementation quality/maintainability ;)]
HTH,
Andreas Mohr
y large amount of LOC extensions
which put certain amounts of stress on
code implementation quality/maintainability ;)]
HTH,
Andreas Mohr
On Mon, Sep 05, 2016 at 08:41:39AM -0400, Tejun Heo wrote:
> On Sun, Sep 04, 2016 at 03:29:39AM +0200, Andreas Mohr wrote:
> > Reason: any other [early-boot] invoker of cancel_delayed_work_sync()
> > would hit the same issue,
> > without any fix then available locally ea
On Mon, Sep 05, 2016 at 08:41:39AM -0400, Tejun Heo wrote:
> On Sun, Sep 04, 2016 at 03:29:39AM +0200, Andreas Mohr wrote:
> > Reason: any other [early-boot] invoker of cancel_delayed_work_sync()
> > would hit the same issue,
> > without any fix then available locally ea
uot;
is the *pre-requisite* for being able to
reliably (atomically) steal work items from work list.
[[hmm, and let's hope that NMIs are (known to be?) not involved]]
HTH,
Andreas Mohr
uot;
is the *pre-requisite* for being able to
reliably (atomically) steal work items from work list.
[[hmm, and let's hope that NMIs are (known to be?) not involved]]
HTH,
Andreas Mohr
s being
hard-pressed to report this rather than
silently ignoring / not even knowing this issue
(in those cases where we already know that
no further development fixes will be determinable,
carrying on with a dire warning probably still is preferable to
making the machine completely unusable, eternally,
though).
Thus, think robustness.
Andreas Mohr
s being
hard-pressed to report this rather than
silently ignoring / not even knowing this issue
(in those cases where we already know that
no further development fixes will be determinable,
carrying on with a dire warning probably still is preferable to
making the machine completely unusable, eternally,
though).
Thus, think robustness.
Andreas Mohr
operly determined
that in fact they *are* RT-type tasks
(the wording of "tg_has_rt_tasks" clearly suggests
that this API does *not* know yet
which task type it currently deals with,
so it does need to figure the type out, reliably,
by *not* directly calling into a fully RT-specific API).
Tha
operly determined
that in fact they *are* RT-type tasks
(the wording of "tg_has_rt_tasks" clearly suggests
that this API does *not* know yet
which task type it currently deals with,
so it does need to figure the type out, reliably,
by *not* directly calling into a fully RT-specific API).
Tha
simply do not have it, thus *we* *RELIABLY* are and will be "not the
owner"
[but note that in that case
this mutex API implementation code would have
a potentially unholy dependency on task stuff such as "current",
but which it probably already has anyway]
HTH,
Andreas Mohr
simply do not have it, thus *we* *RELIABLY* are and will be "not the
owner"
[but note that in that case
this mutex API implementation code would have
a potentially unholy dependency on task stuff such as "current",
but which it probably already has anyway]
HTH,
Andreas Mohr
) seem to be
*users* of a successful printk() *implementation* and thus
most certainly should not have any business whatsoever
also sitting within
the (already sufficiently complex / unreviewable - 3.3k lines!!)
printk() *implementation mechanics* file
HTH & HAND,
Andreas Mohr
) seem to be
*users* of a successful printk() *implementation* and thus
most certainly should not have any business whatsoever
also sitting within
the (already sufficiently complex / unreviewable - 3.3k lines!!)
printk() *implementation mechanics* file
HTH & HAND,
Andreas Mohr
Hello,
On Sun, Mar 20, 2016 at 05:51:23PM -0400, Theodore Ts'o wrote:
> On Sun, Mar 20, 2016 at 06:10:53PM +0100, Andreas Mohr wrote:
> > [ 18.164828] EXT4-fs (sda2): mounting ext3 file system using the ext4
> > subsyste
> > [ 248.211176] EXT4-fs (sda2): recovery compl
Hello,
On Sun, Mar 20, 2016 at 05:51:23PM -0400, Theodore Ts'o wrote:
> On Sun, Mar 20, 2016 at 06:10:53PM +0100, Andreas Mohr wrote:
> > [ 18.164828] EXT4-fs (sda2): mounting ext3 file system using the ext4
> > subsyste
> > [ 248.211176] EXT4-fs (sda2): recovery compl
d" mount activity
would be sufficient,
both for text boot *and* GUI boot with some sufficiently accessible
"boot details" window.
Thanks,
Andreas Mohr
d" mount activity
would be sufficient,
both for text boot *and* GUI boot with some sufficiently accessible
"boot details" window.
Thanks,
Andreas Mohr
de?) part of "x86/urgent",
which I didn't expect to be defined as topically related.
Thanks,
Andreas Mohr
-by Intel and Microsoft which can be found at
> -
> - http://www.intel.com/hardwaredesign/hpetspec_1.pdf
> +by Intel and Microsoft, revision 1.
Oh, and I noticed as a curiosity (or so I thought)
that this cleanup-style work is (to be made?) part of "x86/urgent",
which I didn't expect to be defined as topically related.
Thanks,
Andreas Mohr
ng that this issue is hitting the streets in 2015 -
if we aren't missing something here, that is...
HTH,
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.
ng that this issue is hitting the streets in 2015 -
if we aren't missing something here, that is...
HTH,
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.
Hi,
[lkml.org info remains broken --> "special" reply rather than proper chain :(]
On Tue, Jun 02, 2015 at 09:07:02PM +0200, Andreas Mohr wrote:
> Hi,
>
> I'm wondering whether we're actually recording / retaining
> any info about the precise reason for the machine wake
Hi,
[lkml.org info remains broken -- special reply rather than proper chain :(]
On Tue, Jun 02, 2015 at 09:07:02PM +0200, Andreas Mohr wrote:
Hi,
I'm wondering whether we're actually recording / retaining
any info about the precise reason for the machine wakeup
that was responsible
mediately *without* any prior delay,
in which case the first (AND LAST!) PSMOUSE_CMD_GETID query
after the (your) delay
would now already fail for those devices...
HTH,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
--
To unsubscribe from this list: send th
the first (AND LAST!) PSMOUSE_CMD_GETID query
after the (your) delay
would now already fail for those devices...
HTH,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
n by Andreas
> * Rename debug_kbd to unmask_kbd_data
> * Improve description in Documentation/kernel-parameters.txt
Patch in its entirety seems fine to me, thanks!
Reviewed-by: Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
* Rename debug_kbd to unmask_kbd_data
* Improve description in Documentation/kernel-parameters.txt
Patch in its entirety seems fine to me, thanks!
Reviewed-by: Andreas Mohr and...@users.sf.net
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
_lsusb/
HTH,
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi,
Greg Kroah-Hartman wrote:
On Fri, Jun 26, 2015 at 09:20:19PM -0400, Alan Stern wrote:
I can test it next week, if you would like to see the actual values.
That would be great.
That one? (plus mouse plugged into keyboard hub)
http://lisas.de/~andi/lkml/Apple_A1048_lsusb/
HTH,
Andreas
led*,
i8042.debug_kbd will be implicitly enabled once i8042.debug=1 is available,
which is wrong).
Perhaps write it as something like
"and as pre-condition requires i8042.debug=1 to be enabled too".
Definitely very good to see this (quote) "big problem" corrected!
Than
corrected!
Thanks,
Andreas Mohr
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ch simply do not need spinup)
- finally, it might be questionable *why* (whether) at certain points
we currently need (decide) to do spinup requests -
I guess it's in order to ensure in advance
that the disk will be ready once it actually will be needed, or so
Thank you very much for having c
that the disk will be ready once it actually will be needed, or so
Thank you very much for having come up with this issue HTH,
Andreas Mohr
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
_eriar_cond = 1 loop 100"
Yup, that seems to be
rtl_eri_read() in ethernet/realtek/r8169.c
waiting on low condition of
RTL_R32(ERIAR) & ERIAR_FLAG;
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
, that seems to be
rtl_eri_read() in ethernet/realtek/r8169.c
waiting on low condition of
RTL_R32(ERIAR) ERIAR_FLAG;
Andreas Mohr
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at http://www.tux.org/lkml/
issue, see
https://bugzilla.kernel.org/show_bug.cgi?id=99421
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
/show_bug.cgi?id=99421
Andreas Mohr
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
oposed by Kay Sievers)
While we're quite firmly on the non-kernel side here,
I'll still scribble my
Reviewed-by: Andreas Mohr
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
GE " version " VERSION);
> + puts(KMOD_FEATURES);
> return EXIT_SUCCESS;
Thanks,
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo i
);
return EXIT_SUCCESS;
Thanks,
Andreas Mohr
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
by Kay Sievers)
While we're quite firmly on the non-kernel side here,
I'll still scribble my
Reviewed-by: Andreas Mohr and...@users.sf.net
Andreas Mohr
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
Hi,
On Thu, Jun 04, 2015 at 01:19:46PM +1000, Stephen Rothwell wrote:
> Hi Rusty,
> > But disappointing that Debian doesn't configure with it, and there's no
> > easy way to check it. Looks like Ubuntu vivid is the same.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772628
Crap, that
On Wed, Jun 03, 2015 at 11:31:20PM -0300, Lucas De Marchi wrote:
> On Wed, Jun 3, 2015 at 10:30 PM, Rusty Russell wrote:
> > diff --git a/init/Kconfig b/init/Kconfig
> > index 968a001790af..5422c44be5f0 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -1948,26 +1948,22 @@ config
Hi,
On Thu, Jun 04, 2015 at 01:19:46PM +1000, Stephen Rothwell wrote:
Hi Rusty,
But disappointing that Debian doesn't configure with it, and there's no
easy way to check it. Looks like Ubuntu vivid is the same.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772628
Crap, that URL now
On Wed, Jun 03, 2015 at 11:31:20PM -0300, Lucas De Marchi wrote:
On Wed, Jun 3, 2015 at 10:30 PM, Rusty Russell ru...@rustcorp.com.au wrote:
diff --git a/init/Kconfig b/init/Kconfig
index 968a001790af..5422c44be5f0 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1948,26 +1948,22 @@
it should be documented,
since currently grepping of Documentation/ for wakeup|grep -i reason
does not show any hints.
Thanks,
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More maj
be documented,
since currently grepping of Documentation/ for wakeup|grep -i reason
does not show any hints.
Thanks,
Andreas Mohr
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
han having to resort to clumsy hacks
such as ldd or even strings.
While this is a minor but useful addition
rather than a severe fix,
having a CC to stable@ added subsequently might be useful.
Thanks!
Signed-off-by: Andreas Mohr
---
init/Kconfig | 18 +-
1 file changed, 13 insert
to clumsy hacks
such as ldd or even strings.
While this is a minor but useful addition
rather than a severe fix,
having a CC to stable@ added subsequently might be useful.
Thanks!
Signed-off-by: Andreas Mohr and...@users.sf.net
---
init/Kconfig | 18 +-
1 file changed, 13 insertions
Hi,
> Submitting the following information for kernel bug review.
> [1.] Lenovo SL510 will not resume from suspend
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/power/basic-pm-debugging.txt
might turn out to be quite helpful here.
HTH,
Andrea
Hi,
Submitting the following information for kernel bug review.
[1.] Lenovo SL510 will not resume from suspend
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/power/basic-pm-debugging.txt
might turn out to be quite helpful here.
HTH,
Andreas Mohr
requiring bitops.h
- bitops.h no longer including linux/compiler.h
IMHO explicitly #include:ing parts
which certain code does actively depend on after all
is both a "code honesty"
and a documentation issue ("Hmm, which interfaces does this implementation
depend on? Ah, yeah..."
requiring bitops.h
- bitops.h no longer including linux/compiler.h
IMHO explicitly #include:ing parts
which certain code does actively depend on after all
is both a code honesty
and a documentation issue (Hmm, which interfaces does this implementation
depend on? Ah, yeah...)
Food for thought,
Andreas
's
very limited 2GB/3GB total per Win32 process.
http://blogs.microsoft.co.il/sasha/2014/07/22/tracking-unusable-virtual-memory-vmmap/
"Why is address space allocation granularity 64K?"
http://blogs.msdn.com/b/oldnewthing/archive/2003/10/08/55239.aspx
One thing less left to wonder why
.
http://blogs.microsoft.co.il/sasha/2014/07/22/tracking-unusable-virtual-memory-vmmap/
Why is address space allocation granularity 64K?
http://blogs.msdn.com/b/oldnewthing/archive/2003/10/08/55239.aspx
One thing less left to wonder why 'doze is such a performance pig...
Andreas Mohr
On Tue, Jan 06, 2015 at 09:33:15AM -0600, Christoph Lameter wrote:
> On Tue, 6 Jan 2015, Andreas Mohr wrote:
> > by merely queuing them into a simple submission queue
> > which then will be delay-applied by main-context
> > either once main-context enters a certain "
On Tue, Jan 06, 2015 at 10:31:22AM +0900, Joonsoo Kim wrote:
> Hello,
>
> On Mon, Jan 05, 2015 at 06:21:39PM +0100, Andreas Mohr wrote:
> > Hi,
> >
> > Joonsoo Kim wrote:
> > > + ac->tid = next_tid(ac->tid);
> > (and all others)
>
On Tue, Jan 06, 2015 at 10:31:22AM +0900, Joonsoo Kim wrote:
Hello,
On Mon, Jan 05, 2015 at 06:21:39PM +0100, Andreas Mohr wrote:
Hi,
Joonsoo Kim wrote:
+ ac-tid = next_tid(ac-tid);
(and all others)
object oriented:
array_cache_next_tid(ac);
(or perhaps rather
On Tue, Jan 06, 2015 at 09:33:15AM -0600, Christoph Lameter wrote:
On Tue, 6 Jan 2015, Andreas Mohr wrote:
by merely queuing them into a simple submission queue
which then will be delay-applied by main-context
either once main-context enters a certain quiet state (e.g. context
switch
Hi,
> + if (size == 1)
> + *val = readb(addr);
> + else if (size == 2)
> + *val = readw(addr);
> + else
> + *val = readl(addr);
(pci_generic_config_read() and pci_generic_config_write())
switch()
default: WARN_ON(1);
?
Tha
[CC related ppl]
On Mon, Jan 05, 2015 at 12:10:54PM -0600, Scott Wood wrote:
> On Mon, 2015-01-05 at 18:46 +0100, Andreas Mohr wrote:
> > Hi,
> >
> > > I was curious why the mpic_cpu_read(MPIC_INFO(CPU_WHOAMI)) was there in
> > > the first place and if it's sti
of my *ss without any MPIC specifics here
(and especially not why the readback there actually is needed -
if that doesn't happen to be the case for PCI Posting reasons or some such),
but it's just intended as food for thought :)
*) Real Silicon (rather than RL - Real Life)
HTH,
Andreas Mohr
--
To un
ine)
of whether this change is good (i.e. a clean step in the right direction),
or whether instead the implementation could easily directly be made
fully independent from IRQ constraints.
Thanks,
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
),
or whether instead the implementation could easily directly be made
fully independent from IRQ constraints.
Thanks,
Andreas Mohr
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
there actually is needed -
if that doesn't happen to be the case for PCI Posting reasons or some such),
but it's just intended as food for thought :)
*) Real Silicon (rather than RL - Real Life)
HTH,
Andreas Mohr
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
1 - 100 of 455 matches
Mail list logo
