On Tue, 2022-03-01 at 09:45 -0800, Rob Clark wrote:
> On Mon, Feb 28, 2022 at 10:49 PM David Laight wrote:
> >
> > From: Abhinav Kumar
> > > Sent: 28 February 2022 21:38
> > ...
> > > We also did some profiling around how much increasing the block size
> > > helps and here is the data:
> > >
> >
On Mon, Feb 28, 2022 at 10:49 PM David Laight wrote:
>
> From: Abhinav Kumar
> > Sent: 28 February 2022 21:38
> ...
> > We also did some profiling around how much increasing the block size
> > helps and here is the data:
> >
> > Block sizecost
> >
> > 4KB 229s
> > 8KB86s
From: Abhinav Kumar
> Sent: 28 February 2022 21:38
...
> We also did some profiling around how much increasing the block size
> helps and here is the data:
>
> Block sizecost
>
> 4KB 229s
> 8KB86s
You must have an O(n^2) operation in there - find it.
David
-
R
Hi Johannes and Greg
On 2/12/2022 12:35 AM, Abhinav Kumar wrote:
Hi Johannes
On 2/12/2022 12:24 AM, Johannes Berg wrote:
On Fri, 2022-02-11 at 23:52 -0800, Abhinav Kumar wrote:
The thread is writing the data to a file in local storage. From our
profiling, the read is the one taking the time
Hi Johannes
On 2/12/2022 12:24 AM, Johannes Berg wrote:
On Fri, 2022-02-11 at 23:52 -0800, Abhinav Kumar wrote:
The thread is writing the data to a file in local storage. From our
profiling, the read is the one taking the time not the write.
That seems kind of hard to believe, let's say it'
Hi Greg
On 2/12/2022 12:29 AM, Greg KH wrote:
On Fri, Feb 11, 2022 at 11:52:41PM -0800, Abhinav Kumar wrote:
Hi Greg
On 2/11/2022 11:04 PM, Greg KH wrote:
On Fri, Feb 11, 2022 at 10:59:39AM -0800, Abhinav Kumar wrote:
Hi Greg
Thanks for the response.
On 2/11/2022 3:09 AM, Greg KH wrote:
O
On Fri, Feb 11, 2022 at 11:52:41PM -0800, Abhinav Kumar wrote:
> Hi Greg
>
> On 2/11/2022 11:04 PM, Greg KH wrote:
> > On Fri, Feb 11, 2022 at 10:59:39AM -0800, Abhinav Kumar wrote:
> > > Hi Greg
> > >
> > > Thanks for the response.
> > >
> > > On 2/11/2022 3:09 AM, Greg KH wrote:
> > > > On Tue
On Fri, 2022-02-11 at 23:52 -0800, Abhinav Kumar wrote:
>
> The thread is writing the data to a file in local storage. From our
> profiling, the read is the one taking the time not the write.
>
That seems kind of hard to believe, let's say it's a 4/3 split (4
minutes reading, 3 minutes writing,
Hi Greg
On 2/11/2022 11:04 PM, Greg KH wrote:
On Fri, Feb 11, 2022 at 10:59:39AM -0800, Abhinav Kumar wrote:
Hi Greg
Thanks for the response.
On 2/11/2022 3:09 AM, Greg KH wrote:
On Tue, Feb 08, 2022 at 11:44:32AM -0800, Abhinav Kumar wrote:
There are cases where depending on the size of th
On Fri, Feb 11, 2022 at 10:59:39AM -0800, Abhinav Kumar wrote:
> Hi Greg
>
> Thanks for the response.
>
> On 2/11/2022 3:09 AM, Greg KH wrote:
> > On Tue, Feb 08, 2022 at 11:44:32AM -0800, Abhinav Kumar wrote:
> > > There are cases where depending on the size of the devcoredump and the
> > > spe
Hi Greg
Thanks for the response.
On 2/11/2022 3:09 AM, Greg KH wrote:
On Tue, Feb 08, 2022 at 11:44:32AM -0800, Abhinav Kumar wrote:
There are cases where depending on the size of the devcoredump and the speed
at which the usermode reads the dump, it can take longer than the current 5 mins
tim
On Tue, Feb 08, 2022 at 05:55:18PM -0800, Abhinav Kumar wrote:
> Hi Johannes
>
> On 2/8/2022 1:54 PM, Johannes Berg wrote:
> > On Tue, 2022-02-08 at 13:40 -0800, Abhinav Kumar wrote:
> > > >
> > > I am checking what usermode sees and will get back ( I didnt see an
> > > error do most likely it wa
On Tue, Feb 08, 2022 at 11:44:32AM -0800, Abhinav Kumar wrote:
> There are cases where depending on the size of the devcoredump and the speed
> at which the usermode reads the dump, it can take longer than the current 5
> mins
> timeout.
>
> This can lead to incomplete dumps as the device is dele
Hi Johannes
On 2/8/2022 11:50 PM, Johannes Berg wrote:
On Tue, 2022-02-08 at 17:55 -0800, Abhinav Kumar wrote:
Are you suggesting something like below?
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index 42dcf96..14203d0 100644
--- a/fs/sysfs/file.c
No, for sure not, but I guess from the
On Tue, 2022-02-08 at 17:55 -0800, Abhinav Kumar wrote:
>
> Are you suggesting something like below?
>
> diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> index 42dcf96..14203d0 100644
> --- a/fs/sysfs/file.c
>
No, for sure not, but I guess from the looks of this patch there's no
way to do somet
Hi Johannes
On 2/8/2022 1:54 PM, Johannes Berg wrote:
On Tue, 2022-02-08 at 13:40 -0800, Abhinav Kumar wrote:
I am checking what usermode sees and will get back ( I didnt see an
error do most likely it was EOF ). I didnt follow the second part.
I think probably it got -ENODEV, looking at ke
On Tue, 2022-02-08 at 13:40 -0800, Abhinav Kumar wrote:
> >
> I am checking what usermode sees and will get back ( I didnt see an
> error do most likely it was EOF ). I didnt follow the second part.
I think probably it got -ENODEV, looking at kernfs_file_read_iter().
> If the file descriptor re
Hi Johannes
On 2/8/2022 1:12 PM, Johannes Berg wrote:
On Tue, 2022-02-08 at 13:04 -0800, Abhinav Kumar wrote:
It opened the file rightaway but could not finish reading.
The device gets deleted so the corresponding /data will disappear too (
as the data node is under devcd*/data)
Yeah but ev
On Tue, 2022-02-08 at 13:04 -0800, Abhinav Kumar wrote:
>
> It opened the file rightaway but could not finish reading.
>
> The device gets deleted so the corresponding /data will disappear too (
> as the data node is under devcd*/data)
Yeah but even if the file disappears, the open file descrip
On Tue, 2022-02-08 at 11:44 -0800, Abhinav Kumar wrote:
> There are cases where depending on the size of the devcoredump and the speed
> at which the usermode reads the dump, it can take longer than the current 5
> mins
> timeout.
>
> This can lead to incomplete dumps as the device is deleted onc
Hi Johannes
Thanks for the response.
On 2/8/2022 12:35 PM, Johannes Berg wrote:
On Tue, 2022-02-08 at 11:44 -0800, Abhinav Kumar wrote:
There are cases where depending on the size of the devcoredump and the speed
at which the usermode reads the dump, it can take longer than the current 5 mins
21 matches
Mail list logo
