On Sat, 2023-09-23 at 06:29 +0100, Anton Ivanov wrote:
>
> One more thing. Is your find "real" /bin/find or busybox.
Yeah, definitely real find, it's my normal host system with hostfs after
all :)
johannes
___
linux-um mailing list
linux-um@lists.infr
On 22/09/2023 21:12, Johannes Berg wrote:
On Fri, 2023-09-22 at 21:08 +0100, Anton Ivanov wrote:
On 22/09/2023 20:41, Johannes Berg wrote:
On Fri, 2023-09-22 at 14:41 +0100, Anton Ivanov wrote:
It is nearly twice slower than the current approach on a find /usr -type f -exec
cat {} > /dev/nul
On 22/09/2023 21:12, Johannes Berg wrote:
On Fri, 2023-09-22 at 21:08 +0100, Anton Ivanov wrote:
On 22/09/2023 20:41, Johannes Berg wrote:
On Fri, 2023-09-22 at 14:41 +0100, Anton Ivanov wrote:
It is nearly twice slower than the current approach on a find /usr -type f -exec
cat {} > /dev/null
On Fri, 2023-09-22 at 21:08 +0100, Anton Ivanov wrote:
> On 22/09/2023 20:41, Johannes Berg wrote:
> > On Fri, 2023-09-22 at 14:41 +0100, Anton Ivanov wrote:
> > >
> > > It is nearly twice slower than the current approach on a find /usr -type
> > > f -exec cat {} > /dev/null \;
> > >
> >
> > Bt
On 22/09/2023 20:41, Johannes Berg wrote:
On Fri, 2023-09-22 at 14:41 +0100, Anton Ivanov wrote:
It is nearly twice slower than the current approach on a find /usr -type f -exec
cat {} > /dev/null \;
Btw, I cannot reproduce that at all - seems about the same in my tests?
Is there anything
On Fri, 2023-09-22 at 14:41 +0100, Anton Ivanov wrote:
>
> It is nearly twice slower than the current approach on a find /usr -type f
> -exec cat {} > /dev/null \;
>
Btw, I cannot reproduce that at all - seems about the same in my tests?
Is there anything special in your setup?
Or maybe it's
On Fri, 2023-09-22 at 13:16 +0200, Johannes Berg wrote:
> Note that this fixes what seems like an issue - we look
> at current->mm when we copy, but that doesn't seem right
> in the case of clone() without copying the MM. This is
> probably saved by the forced flush later right now.
>
After findi
On Fri, 2023-09-22 at 13:16 +0200, Johannes Berg wrote:
>
> - /* Set parent's instruction pointer to start of clone-stub */
> - thread_regs[REGS_IP_INDEX] = STUB_CODE +
> - (unsigned long) stub_clone_handler -
> - (unsigned long) __sy
On 22/09/2023 16:31, Benjamin Berg wrote:
Hi,
On Fri, 2023-09-22 at 14:41 +0100, Anton Ivanov wrote:
On 22/09/2023 12:16, Johannes Berg wrote:
From: Johannes Berg
While enabling PREEMPT on UML, we found that the call to
force_flush_all() cannot be done where it is, it sleeps
while atomic.
Hi,
On Fri, 2023-09-22 at 14:41 +0100, Anton Ivanov wrote:
>
> On 22/09/2023 12:16, Johannes Berg wrote:
> > From: Johannes Berg
> >
> > While enabling PREEMPT on UML, we found that the call to
> > force_flush_all() cannot be done where it is, it sleeps
> > while atomic.
> >
> > Further invest
On Fri, 2023-09-22 at 14:41 +0100, Anton Ivanov wrote:
> On 22/09/2023 12:16, Johannes Berg wrote:
> > From: Johannes Berg
> >
> > While enabling PREEMPT on UML, we found that the call to
> > force_flush_all() cannot be done where it is, it sleeps
> > while atomic.
> >
> > Further investigation
On Fri, 2023-09-22 at 13:16 +0200, Johannes Berg wrote:
> From: Johannes Berg
>
> While enabling PREEMPT on UML, we found that the call to
> force_flush_all() cannot be done where it is, it sleeps
> while atomic.
>
> Further investigation shows that all this seems at least
> a bit roundabout and
On 22/09/2023 12:16, Johannes Berg wrote:
From: Johannes Berg
While enabling PREEMPT on UML, we found that the call to
force_flush_all() cannot be done where it is, it sleeps
while atomic.
Further investigation shows that all this seems at least
a bit roundabout and possibly wrong wrong in t
13 matches
Mail list logo
